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
Peter Alfke wrote: > > I am looking at revamping the FIFO cores, giving you many options: > asynchr. vs synchronous, with exact empty and full > extra one-clock-early empty and full indicators Interesting - this would allow a smaller fifo for continual streaming output ? > programmable almost empty and full indicators, > readable occupied size , > etc > Any additional suggestions? Newer UART fifos have a WDOG type feature, where a montostable timer (runs at some multiple character time), generates an interrupt if ever bytes are 'left in the FIFO', but under the interrupt threshold. Allows a fully interrupt design, and avoids separate polling to check for remnant data, which might be a noise side-effect. -jgArticle: 56101
Amontec Team wrote: > > Hi all, > > I have to find the best solution to do a TTL level converter. > I have to convert 5v <-> 3.3v 2.5v 1.8v 1.2v. > > I have an external Vref signal for the second part. > I have some bidirectional signal :-( > > The shem would be some think like this: > > Ĥ-------------Ĥ > Ĥ +<----- Vref from 1.2v to 3.3v > Ĥ Ĥ > Ĥ TTL level Ĥ > 5v TTL signals <--->+ converter +<----> 1.2v to 3.3v LVTTL signals > Ĥ-------------Ĥ depending on Vref > > Which solutions to do that? > Is there any device to do that? The wider spec LVDS devices should be good for this. They are effectively (very) fast comparitors designed for digital use, and come in a range of voltages and widths. -jgArticle: 56102
"Peter Alfke" <peter@xilinx.com> wrote in message news:3ED51C5D.3B8A1565@xilinx.com... > I am looking at revamping the FIFO cores, giving you many options: > asynchr. vs synchronous, with exact empty and full > extra one-clock-early empty and full indicators > programmable almost empty and full indicators, > readable occupied size , > etc > Any additional suggestions? Like the old NEC uPD42101. In clock, in enable, in reset (synchronous). Out clock, out enable, out reset (synchronous). Contents can be read multiple timesArticle: 56103
Jim Granville wrote: > Amontec Team wrote: > >>Hi all, >> >>I have to find the best solution to do a TTL level converter. >>I have to convert 5v <-> 3.3v 2.5v 1.8v 1.2v. >> >>I have an external Vref signal for the second part. >>I have some bidirectional signal :-( >> >>The shem would be some think like this: >> >> Ĥ-------------Ĥ >> Ĥ +<----- Vref from 1.2v to 3.3v >> Ĥ Ĥ >> Ĥ TTL level Ĥ >>5v TTL signals <--->+ converter +<----> 1.2v to 3.3v LVTTL signals >> Ĥ-------------Ĥ depending on Vref >> >>Which solutions to do that? >>Is there any device to do that? > > > The wider spec LVDS devices should be good for this. > They are effectively (very) fast comparitors designed for digital use, > and come in a range of voltages and widths. > > -jg Have you some good www entry points ?Article: 56104
Amontec Team wrote: > > Jim Granville wrote: > > > Amontec Team wrote: > > > >>Hi all, > >> > >>I have to find the best solution to do a TTL level converter. > >>I have to convert 5v <-> 3.3v 2.5v 1.8v 1.2v. > >> > >>I have an external Vref signal for the second part. > >>I have some bidirectional signal :-( > >> > >>The shem would be some think like this: > >> > >> Ĥ-------------Ĥ > >> Ĥ +<----- Vref from 1.2v to 3.3v > >> Ĥ Ĥ > >> Ĥ TTL level Ĥ > >>5v TTL signals <--->+ converter +<----> 1.2v to 3.3v LVTTL signals > >> Ĥ-------------Ĥ depending on Vref > >> > >>Which solutions to do that? > >>Is there any device to do that? > > > > > > The wider spec LVDS devices should be good for this. > > They are effectively (very) fast comparitors designed for digital use, > > and come in a range of voltages and widths. > > > > -jg > > Have you some good www entry points ? http://www.national.com/parametric/0,1850,1624,00.html http://www.fairchildsemi.com/products/interface/lvds.html there are quite a few LVDS players, so it's quite a well resourced field. -jgArticle: 56105
Gee, and I thought it had something to do with trying to ensure that companies that manufacture drills made a profit. "Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qhbrxm24a3.fsf@ruckus.brouhaha.com... > Keith R. Williams <krw@btv.ibm.com> writes: > > Why do you think pads and vias are round. ;-) > > Because donuts are so tasty?Article: 56106
"Robert" <rpudlik@poczta.onet.pl> ha scritto nel messaggio news:3ED4C3FC.10006@poczta.onet.pl... > Does anyone knows when new Xilinx serial PROMs (e.g > XCF02S) will be > available? I don't see them at distributors yet. XCF01S and XCF02S are already available, either as "engineering samples" and normal parts. At least this is what my Xilinx distributor (from Avnet Silica) told me, but I still haven't any samples. The prices are around 3 euro for '01 and 7 euro for '02. -- LorenzoArticle: 56107
Magnus Homann wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > > I am finding JTAG to be a major hassle to try to use for both debug and > > production boundary scan. Seems there are conflicting requirements > > which the two camps are not generally interested in dealing with. > > RISCTrace/Watch from IBM used to have the same issues. We had the > PowerPC in the middle of the chain. > > If I remember correctly we (i.e. my colleague) solved this by: > > 1) connecting all TMS and TCK in parallel. > > 2) rotuing TDI/O from part A to connector X to part P and split to > connector X and part B (see fig). > > 3) When debugging, connector was used so that only part P was in the > chain. Pullups on TDI for other parts kept them out of trouble. > > 4) When tetsing for production, connector was used so that the entire > chain was used (strap in X to connect TDo of A with TDI on P). > > 5) The last part could also be achieved with resistor. > > The issue with long stubs on TDI/O we didn't think mattered, > considering it's a synchronous system with a failry low system clock. TCK on the other hand was routed as a long clock winding to all parts and ending in a Thevenin termination. > > All this from memory, if it doesn't work, blame someone else. > > (fig 1) > > |--------| |--------| |--------| > --| part A |--| |--| part P |-----| part B |--- > |--------| | | |--------| | |--------| > | | | > | | | > |----------------------| > | connector X | > |----------------------| I like most of what you said, but I don't think you can *debug* the board with all the TMS and TCK signals in parallel. This would send the same instructions to all devices and put them in a possibly poor state for normal operation when you only intended to be controlling part P. I expect to have to use jumpers to disable the TRST, TMS or TCK inputs on all parts other than P. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56108
It was early. I wasn't in my right mind! And I replied on the wrong thread. ;) But alas it's not important now because well I'm tired again. "Jerry Avins" <jya@ieee.org> wrote in message news:3ED4EE8D.7B729A22@ieee.org... > Brett Foster wrote: > > > > Well this was actually meant for the serious posters silly. > > > > "Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message > > news:bb29ag$q5u$1@nets3.rz.RWTH-Aachen.DE... > > > In comp.arch.embedded Brett Foster <custserv@forums.ws> wrote: > > > > I thought this was largely disproven. Or at least the effect rather > > minimal > > > > (negligible). > > > > > > Depends on what kind of "trace" you're talking about. ;-P > > > > > > If it happens to be a proper race track for electrons, a.k.a. > > > high-energy particle accelerator, you'll have a rather "interesting" > > > time trying to survive standing on the outside of any of its curved > > > segments without heavy shielding in between. Kids: please _don't_ try > > > this at home! > > > -- > > > Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) > > > Even if all the snow were burnt, ashes would remain. > > Come, now! CBFalconer's remark was a joke in the first place. Injury? > Smiley! > > Jerry > -- > Engineering is the art of making what you want from things you can get. > ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 56109
rickman wrote:
> Eric Bohlman wrote:
>
>>Spam Hater <spam_hater_7@email.com> wrote in
>>news:jve7cvgldg4va3thk6pbubq18rjuh07van@4ax.com:
>>
>>>I always forget which one is which, but I prefer the one where the
>>>outputs come directly from the flops. And yes, it's a -personal-
>>>bias.
>>
>>That's true of a correct implementation of either model. In a Mealy
>>machine, the output at time t+1 is a function of both the current state at
>>time t and the input at time t. In a Moore machine, the output is a
>>function of the current state only. Some people implement Mealy machines
>>sloppily, with the output being a *combinatorial* function of the current
>>state and the input, but that's not an inherent characteristic of the
>>model.
>
> Actually, that is not the "sloppy" Mealy machine, it is the literal
> Mealy machine. If you register the outputs in a Mealy machine so that
> the outputs are a function of the previous inputs and state, you have
> simply converted your machine to a Moore machine while leaving the
> outputs out of the state description. But it is still a Moore machine.
See the state machine example elsewhere in this thread with output ACK.
The output is registered in each case.
The timing is the same in each case.
The trick is that an output register can combine either the D or Q side of the
state register.
-- Mike Treseler
Article: 56110On Tue, 27 May 2003 23:52:22 GMT, CBFalconer <cbfalconer@yahoo.com> wrote: >Brett Foster wrote: >> "Mike Rosing" <rosing@neurophys.wisc.edu> wrote in message >> > >> > The short stubs are important, and the traces shouldn't have >> > any sharp angles - you want a really clean signal all around. >> > I assume you've got ground planes and not a 2 layer board? >> > That'll help a lot too. >> >> Why no sharp angles? > >Those electrons are moving at an appreciable fraction of the speed >of light, and tend to oversteer. The rear end breaks loose going >around those corners, and they are likely to go straight through >the wall and injure somthing. :-) Nothing softer rear springs and bigger front swaybars won't cure. They just have to be really, really small. Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.orgArticle: 56111
It's weird, though, even when the drill bit is square the hole comes out round! I always figure that's why vias are round, so the manholes don't fall though them... ...I think. If I don't think, am I not? I'd better stop now. On Wed, 28 May 2003 21:36:54 GMT, "Charles Krinke" <someone@pacbell.net> wrote: >Gee, and I thought it had something to do with trying to ensure that >companies that manufacture drills made a profit. > >"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message >news:qhbrxm24a3.fsf@ruckus.brouhaha.com... >> Keith R. Williams <krw@btv.ibm.com> writes: >> > Why do you think pads and vias are round. ;-) >> >> Because donuts are so tasty? > > Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.orgArticle: 56112
hi all, need some help on this, need to send about 500Mbit/s of data(images) between our equipment 100 ft (30 meter ) apart. we have rule out USB 2.0 and Firewire, because of the distance. both are about 5 meter per segment (as I understand). so we are thinking of using Gigabit Ethernet, just the phy if possible. I am not too familiar with the Gigabit Ethernet, so here is the question 1) how difficult to create a custom-built interface in Xilinx Virtex II to GMII or TBI, just to transfer data? any pointer, link , that I could read about the GMII? I try google, but most of them is talking about interfacing with the MAC. not much on the protocol of GMII. 2) or must we use a MAC and implement TCP/IP stack? we trying to avoid that. 3) we are looking at LVDS too, National claim to be able to drive 300meter of cable with an Adjustable Output cable driver CLC001, any one have experience with it ? any comments,link, pointer are welcome. thanks pyngArticle: 56113
Alfredo wrote: > Hi, > I've been experimenting with xflow, but I still do not see why I would > use it instead of a makefile, or within a script (c-shell, tcl, perl, > etc.) > > It is hard to tell from Xilinx's documentation what the value of xflow > is. But for one thing, it seems to be used in the edk environment to > automate the build process. > > Any comments? As best I can tell xflow doesn't work properly under Linux/Wine either - the rest of the synthesis tools do (not libgen or platgen for EDK though). xflow doesn't seem to get a lot of use though - it seems many people just do as you suggest and script things themselves. I use it to generate scripts (the -norun option produces equivalent .bat and .tcl scripts) which I then run from within my own scripts. JohnArticle: 56114
Eric Jacobsen wrote: > > It's weird, though, even when the drill bit is square the hole comes > out round! I use three-sided bits to drill square holes. I make mine from worn out three-square* files, but you can buy them. http://www.integerspin.co.uk/polygon.htm ... Jerry ______________________ * A stupid name I didn't make up. -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 56115
On Wed, 28 May 2003 15:36:41 -0700, rickman wrote: > Magnus Homann wrote: >> >> rickman <spamgoeshere4@yahoo.com> writes: >> >> > I am finding JTAG to be a major hassle to try to use for both debug >> > and production boundary scan. Seems there are conflicting >> > requirements which the two camps are not generally interested in >> > dealing with. >> >> RISCTrace/Watch from IBM used to have the same issues. We had the >> PowerPC in the middle of the chain. >> >> If I remember correctly we (i.e. my colleague) solved this by: >> >> 1) connecting all TMS and TCK in parallel. >> >> 2) rotuing TDI/O from part A to connector X to part P and split to >> connector X and part B (see fig). >> >> 3) When debugging, connector was used so that only part P was in the >> chain. Pullups on TDI for other parts kept them out of trouble. >> >> 4) When tetsing for production, connector was used so that the entire >> chain was used (strap in X to connect TDo of A with TDI on P). >> >> 5) The last part could also be achieved with resistor. >> >> The issue with long stubs on TDI/O we didn't think mattered, >> considering it's a synchronous system with a failry low system clock. >> TCK on the other hand was routed as a long clock winding to all parts >> and ending in a Thevenin termination. >> >> All this from memory, if it doesn't work, blame someone else. >> >> (fig 1) >> >> |--------| |--------| |--------| >> --| part A |--| |--| part P |-----| part B |--- >> |--------| | | |--------| | |--------| >> | | | >> | | | >> |----------------------| >> | connector X | >> |----------------------| > > I like most of what you said, but I don't think you can *debug* the > board with all the TMS and TCK signals in parallel. This would send the > same instructions to all devices and put them in a possibly poor state > for normal operation when you only intended to be controlling part P. I > expect to have to use jumpers to disable the TRST, TMS or TCK inputs on > all parts other than P. Should be no problem, all non-tested parts would first be put in bypass mode, (instructions come from TDI, not TMS) Whether the software you have will DTRT is another question... PCWArticle: 56116
The May 2003 issue of IEEE Spectrum has a nifty and detailed article on the exciting British Beagle 2 lander hitching a ride on ESA's Mars Express orbiter, set to launch soon and arrive in December. Its robotic arm carries a bunch of instruments and other devices. "Discrete electronic interfaces between each instrument and the lander would have been complex to build and heavy as well. So the PAW uses a single interface with a field-programmable gate array that can reconfigure itself to match each instrument's needs." Excellent! One of you must be able to tell us more. Who's the clever designer? Who's the lucky vendor? What device? Rad-hard? Fault-tolerant? Designed in what language? Verified how? Bitstreams stored where and loaded by what? Can they upload new bitstreams from Earth? (Now that's an UPload!) What if DONE doesn't go high? Will this be the first FPGA in Mars space? Most important of all, will they send a paper to FPL 2003 or FPGA 2004 or FCCM 2004? --MikeArticle: 56117
Keith Larson wrote: > Hi Rick > > The #1 challenge I can think of is to ensure a clean TCLK. Basically > TCLK is used to sample all of the other signals and as long as those are > stable when TCLK transistions (cleanly), all should be well. > > The underlying tricks that I can think of are... > > 1) Routing a clean TCLK to all devices simultaneosly. A bad example [...] > 2) Do not push the TCLK rate so high that the setup and hold times are > violated. That is, resulting in clean and stable signals at the time of > the (clean) TCLK edge. [...] That's really the bottom line, make TCLK clean and most all other problems are gone. > You will note however that the JTAG header pinout is *not* the same, nor > can it be considering what it does. This makes swapping in and out > other vendors JTAG tools a pain in the butt, because you would need to > create header adapters. Simple, but I dont see any other way except to > isolate the various JTAG chains. > > Maybe someone could comment on the standardization of the JTAG test port > header (there might not be one?). I don't see how. ADI has one EMU line and TI has 2. The other signals are standard, but the order at the header is arbitrary. It's even worse than the RS-232 "standard", you have lots of choices :-) You can have one header for standard i/o pin testing and one header for debugging, just use a switch to select the operation being performed. But if the debug tool knows how to read bsdl files, it should be able to pass the info thru all the chips in the chain correctly. I suspect it would really screw up the timing on the EMUx lines in a multi processor board if you alternated cpld's with dsp's tho. Patience, persistence, truth, Dr. mike -- Mike Rosing www.beastrider.com BeastRider, LLC SHARC debug toolsArticle: 56118
Yes, I'v thought about the frequency doubler. But what I'm afraid of is: would any delay be introduced between fin and fout, for there is no guarantee of de-skew. Anyway, I would use it as "a tool of last resort". "Austin Lesea" <Austin.Lesea@xilinx.com> ??????:3ED4C5C4.CCA011EA@xilinx.com... > Yes, > > One can put the input through a simple frequency doubler (see Peter's > circuit tricks Xclusive), and then into the input. This gets the > frequency down to 12 MHz for the DLL. One then uses the duty cycle > correction ON (to help fix the asymmetry of the doubled clock). Since > taps are updated every 6 times the 2's complement of the jitter filter > settings, the asymmetry of the doubled clock does not violate the input > jitter specification. > > Haven't tried this, but there is no reason why it shouldn't work. If > anyone has it working, let us know. > > Austin > > Heavenfish wrote: > > > > So my question is if there any alternate way to implement both DLL and DFS > > function when my input clk is less than 24MHz? > > or I have to change my application. > > > > "Austin Lesea" <Austin.Lesea@xilinx.com> > > ??????:3ED3C590.F0C93004@xilinx.com... > > > Jon, > > > > > > The DCM CLKFX feature works down to a 1 MHz input frequency (as long as > > > the output being synthesized is greater than 24 MHz). > > > > > > Note that you can not use "sync to DLL" (ie connect CLK0 to CLKFB) in > > > this mode (DFS only mode). > > > > > > AustinArticle: 56119
Mike Treseler wrote: > > rickman wrote: > > Eric Bohlman wrote: > > > >>Spam Hater <spam_hater_7@email.com> wrote in > >>news:jve7cvgldg4va3thk6pbubq18rjuh07van@4ax.com: > >> > >>>I always forget which one is which, but I prefer the one where the > >>>outputs come directly from the flops. And yes, it's a -personal- > >>>bias. > >> > >>That's true of a correct implementation of either model. In a Mealy > >>machine, the output at time t+1 is a function of both the current state at > >>time t and the input at time t. In a Moore machine, the output is a > >>function of the current state only. Some people implement Mealy machines > >>sloppily, with the output being a *combinatorial* function of the current > >>state and the input, but that's not an inherent characteristic of the > >>model. > > > > Actually, that is not the "sloppy" Mealy machine, it is the literal > > Mealy machine. If you register the outputs in a Mealy machine so that > > the outputs are a function of the previous inputs and state, you have > > simply converted your machine to a Moore machine while leaving the > > outputs out of the state description. But it is still a Moore machine. > > See the state machine example elsewhere in this thread with output ACK. > The output is registered in each case. > The timing is the same in each case. > The trick is that an output register can combine either the D or Q side of the > state register. You can put registers anywhere you want in a design. But neither Moore nor Mealy machines have registers on the output values unless the outputs happen to be the same as your state variables. In both machines the outputs are combinatorial functions of the state variables and in the case of the Mealy machine, also the inputs. Adding a register adds a delay to the output and in reality is modeled accurately by a Moore machine where the state variable included all registers, both the original state bits and the registered output bits. S = f(S, I) O = f(S, I) *Mealy* O = f(S) *Moore* By adding the register to the outputs, you make the output a function of the *previous* state and/or inputs, not the current state. You can define the output register input functions so that the outputs change on the same sets of inputs and states as the state register, but then the output registers become "state" registers. If you look at the outputs this way, you will see that treating them as Moore machine state variables makes the programming much simpler. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56120
"Peter C. Wallace" wrote: > > On Wed, 28 May 2003 15:36:41 -0700, rickman wrote: > > > Magnus Homann wrote: > >> > >> (fig 1) > >> > >> |--------| |--------| |--------| > >> --| part A |--| |--| part P |-----| part B |--- > >> |--------| | | |--------| | |--------| > >> | | | > >> | | | > >> |----------------------| > >> | connector X | > >> |----------------------| > > > > I like most of what you said, but I don't think you can *debug* the > > board with all the TMS and TCK signals in parallel. This would send the > > same instructions to all devices and put them in a possibly poor state > > for normal operation when you only intended to be controlling part P. I > > expect to have to use jumpers to disable the TRST, TMS or TCK inputs on > > all parts other than P. > > Should be no problem, all non-tested parts would first be put in bypass > mode, (instructions come from TDI, not TMS) > > Whether the software you have will DTRT is another question... But if you are driving part P with TDI, how do you drive the other parts with a different serial stream? Surely you are not suggesting that the daisy chain be changed in the middle of debugging? As to the software, that is the cruxt of the problem. If the software worked well with other devices in the chain, there would be no problem at all. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 56121
On Wed, 28 May 2003 21:15:36 -0700, rickman wrote: > "Peter C. Wallace" wrote: >> >> On Wed, 28 May 2003 15:36:41 -0700, rickman wrote: >> >> > Magnus Homann wrote: >> >> >> >> (fig 1) >> >> >> >> |--------| |--------| |--------| >> >> --| part A |--| |--| part P |-----| part B |--- >> >> |--------| | | |--------| | |--------| >> >> | | | >> >> | | | >> >> |----------------------| >> >> | connector X | >> >> |----------------------| >> > >> > I like most of what you said, but I don't think you can *debug* the >> > board with all the TMS and TCK signals in parallel. This would send >> > the same instructions to all devices and put them in a possibly poor >> > state for normal operation when you only intended to be controlling >> > part P. I expect to have to use jumpers to disable the TRST, TMS or >> > TCK inputs on all parts other than P. >> >> Should be no problem, all non-tested parts would first be put in bypass >> mode, (instructions come from TDI, not TMS) >> >> Whether the software you have will DTRT is another question... > > But if you are driving part P with TDI, how do you drive the other parts > with a different serial stream? Surely you are not suggesting that the > daisy chain be changed in the middle of debugging? Its the same stream, different parts get different instructions loaded depending on where they are in the stream, unused chips get bypass instructions in their part of the TDI bitsteam, the DUT gets whatever is needed. If the debug tools can't do the right thing with daisy chained parts, another option is to tie all the TDI's, TDO's and TCKs together and do a "chip select" by connecting the desired TMS to the JTAG probe (the other TMS's having pullups) This is called "star" mode in TIs JTAG tutorial... > > As to the software, that is the cruxt of the problem. If the software > worked well with other devices in the chain, there would be no problem > at all.Article: 56122
Hi all, I'm building a new site www.fpga4fun.com It's still under construction but it has already one HDL tutorial/FPGA project. I also made a digital scope that is pretty cool, I'll post the design in the next weeks. Please check the site out and let me know how can I improve it! Thanks. JeanArticle: 56123
On 28 May 2003 16:49:07 -0700, ospyng@yahoo.com (spyng) wrote: >hi all, >need some help on this, > >need to send about 500Mbit/s of data(images) between our equipment 100 >ft (30 meter ) apart. we have rule out USB 2.0 and Firewire, because >of the distance. both are about 5 meter per segment (as I understand). >so we are thinking of using Gigabit Ethernet, just the phy if >possible. I am not too familiar with the Gigabit Ethernet, so here is >the question > >1) how difficult to create a custom-built interface in Xilinx Virtex >II to GMII or TBI, just to transfer data? any pointer, link , that I >could read about the GMII? I try google, but most of them is talking >about interfacing with the MAC. not much on the protocol of GMII. > I don't think it is worth the effort to work at GMII level. You need to implement MAC functionality yourself which is not trivial for 1000B Ethernet. >2) or must we use a MAC and implement TCP/IP stack? we trying to avoid >that. You don't necessarily have to implement tcp/ip. For point to point apps like yours, just a mac and a custom processing engine would be good enough. I suggest you hook up a MAC to a Virtex and process your own packets in the FPGA. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 56124
Hi, I need to implement 20 (one hot) to 5 encoder. The result would cover 21 codes of the 32 available (one for no input active case). I am hoping that I can do better than binary encoding. The question is how do I find an optimal encoding where any unique assignment of the 21 codes with the remaining codes assigned in a don't care fashion would be acceptable. The optimality criteria can be minimum area (say minimum number of 2 input gates). One way woul be to write a script which generates Verilog rtl for all 2^32 possible assignments and run the synthesizer for a long time trying all of them. Any other good ways ? Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations
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