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
Steve Lass <lass@xilinx.com> wrote in message news:<bs79d2$84a1@cliff.xsj.xilinx.com>... > ISE 6.2i will support the Parallel 4 cable on Linux. Thats great. So what am I supposed to do in the mean while ? Shut down my company until you guys make your software work with your hardware ? Seriously, this is a real problem, and nobody seems to have a solution. I tries modifying the software in app 058, but that also needs a PC piece of SW to translate svf to xsvf files. Can you, Steve, or somebody else at Xilinx provide a Linux version (or source code) for the svf to xsvf translator ? Also, in the answer records, it states the schematic for parallel cable 4 is unavailable because it is a "proprietary" design. This seems to me really nonsense, you guys make money with FPGAs not with cables. releasing the schematic will enable users to support them selves when you guys can't. Could you please ask the appropriate people to reconsider this choice ? Do you have a date for 6.2i (patch?) ? Thanks, rudi ======================================================== ASICS.ws ::: Solutions for your ASIC/FPGA needs ::: ..............::: FPGAs * Full Custom ICs * IP Cores ::: FREE IP Cores -> http://www.asics.ws/ <- FREE EDA ToolsArticle: 64301
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:H1ZFb.1797$oA5.541@newssvr25.news.prodigy.com... > Apparently there's something called "Pentium4 Extreme"? > Are marketing guys making it confusing on purpose? > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian Yes, they took a xeon, and put it in a p4 package to try and counter the athlon 64. Mainly to make sure they stay ahead in the bench tables on the various games web sites. Can only be run in single proccessor system. Alex GibsonArticle: 64302
"Lost Temper" <305liuzg@163.net> wrote in message news:<bsgr23$1dpt$1@mail.cn99.com>... > Hi > I can't find the verilog model for AM29LV800B in www.amd.com. > Please send me the model. > Thanks and Regards Hi, man! You can ask AMD for it. I think it is free to use.Article: 64303
Sorry to disappoint you: The XC2S300E has 16 BlockRAMs, each of which has 4096 bits, for a total of 64K bits. There are also over 6000 Look-Up Tables, each of which can be configured as a 16-bit RAM. If you need 8 megabytes of RAM, you have to go off-chip. This applies to any FPGA from any manufacturer. FPGA chip area is too precious for such large memories. Peter Alfke, Xilinx =================================== Carlos wrote: > Hi, > > Does anyone know how much SRAM is available on the XILINX XC2S300E SPARTAN > IIE FPGA? Am I right in thinking it's 8096K Bytes? I'm planning on using > the RAM32X1S module, I was wondering how many can I have inside a single > FPGA. > > Thanks for any help,Article: 64304
Hi, Does anyone know how much SRAM is available on the XILINX XC2S300E SPARTAN IIE FPGA? Am I right in thinking it's 8096K Bytes? I'm planning on using the RAM32X1S module, I was wondering how many can I have inside a single FPGA. Thanks for any help,Article: 64305
So I have a Memec P7 evaluation board with the EDK and a Parallel 4 download cable. We are doing something very basic here to just get our feet wet. All we are doing is writing to the UART a simple hello world program. We wrote some C code, and then stepped through the base system builder using this board. We went thru all the steps in the EDK and downloaded right from the EDK to the board. Hooked up Hyperterm and viola- there was hello world. Hit reset on the board and there it was again. So far so good. Then I figured I would go into the debugger and check out the SDRAM. Run XMD- connect to the debugger and write to the SDRAM. The values do not stick. Odd. So I exit the debugger completely and simply hit the reprogram button in EDK. It says it downloaded the bit file but now hello world doesn't work. I am simply reprogramming the FPGA here. It doesn't work. I reset the program, the PC, the eval board, everything. It no longer works. I cannot get hello world to work again. I do a make clean in EDK (both HW and SW). Nothing. So I reprogram the FPGA and connect with the debugger. Now the program does not work- but I can write to the SDRAM locations and they stick. I repeated this a couple of times. If I build a system from scratch it will work. If I use one after I download and open the debugger- it does not work. I attempted to trace the program- but my SW guy is on holiday. It craps out on some MTCTR instruction. Some special purpose register move thing. Our FAE is stumped to. Anyone seen anything like this? I would thing- reprogram the bit file into a UART that has been reset- you should be good. Apparently, not in this case. Thanks, MSArticle: 64306
Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<bsa1a102rfm@enews3.newsguy.com>... > The Verilog they provided is (just counter section within an always @ > (posedge clk) begin procedural construct): > > //Counter section: > if(run) begin > if(dir) begin > q[3:1] = q[2:0]; //Shift lower bits (Left Shift) > q[0] = !q[3]; //Circulate inverted MSB to LSB > end > else begin > q[2:0] = q[3:1]; //Shift upper bits (Right Shift) > q[3] = !q[0]; //Circulate inverted LSB to MSB > end > end Jeez. More blocking assignments in clocked always blocks! Further proof of my assertion that models and examples are built by a company's most junior engineers, and that the companies involved don't bother checking anything before throwing it up on the web. The only possible explanation is that they just don't care. If we can't trust the examples, how can we trust the post-P&R simulation models? --aArticle: 64307
I'm speaking of density on the device scale. I agree, if you look just at the M512, then you
have a denser filter than if you look at the equivalent number of LUTs. When you look at the
device scale, you don't have very many M512s relative to the number of LUTs. I am familiar with
the Stratix, and did a careful comparative analysis for one of the FPGA vendors between tbe
Stratix and Virtex architectures. That vendor also was not aware of all that could be done with
the SRL16.
Also, yes, you would use it in the widest configurations to get the most efficient use. As a
32x16 you are effectively equivalent to 30 SRL16s plus a 16 bit adder. With DA, you only use
one shift-accumulate after summing all of the partial products. In the limit, using SRL'16s you
use 2 LUTs per coefficient bit for every 4 taps (one lut for the DA LUT, one for part of your
partial adder). In equivalent terms, the M512 replaces about 46 LE's in a non-programmable DA
filter. Additionally, you'll still need your tap delays, which means either additional memories
or flip-flops in the LEs. My point is for a given marketing gate sized device, you can get a
considerably larger DA filter in a device with SRL16's than you can in a device with M512's at
the current M512 to LUT densities.
Michael S wrote:
> Ray Andraka <ray@andraka.com> wrote in message news:<3FE9C209.66051EED@andraka.com>...
> > A DA LUT contains all the possible sums of the input taps, which for a serial filter is
> > one tap per address bit. As you increase the number of taps, the corresponding table size
> > grows exponentially. With LUTs, you get 4 taps per LUT (which you can do with LE's
> > provided you don't need to reload the LUTs). If you have to reload them, then using an
> > M512 only gives you 9 taps per M512, and each M512 is associated with a number of LABs,
> > each containing 10 LEs. Thus the density of a reloadable DA LUT using the DA_LUTs is
> > considerably lower than what you'd get if using LEs.
> >
>
> There are two possibilities:
> 1. I am totally clueless about DA.
> 2. You have never read Stratix datasheet and have no idea what is
> M512.
> Understandably, I prefer the 2nd option.
>
> Nobody in his right mind will use M512 for DA in 512x1b configuration,
> like you suggest. The natural configuration would be 32x16b or 32x18b.
> In such configurations one M512 provides 25% more DA bandwidth than 16
> (or 18, depending on required precision) SRL16 cells. So we can say
> that one M512 replaces 20 (or 22.5) SRL16 cells. Additionally, each
> shift-accumulate block is amortized over 25% more taps, providing
> additional space saving.
> Taking all this into account, I don't believe that M512 is less dense
> than SRL16. Less available - probably yes, but not less dense.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 64308Hi I can't find the verilog model for AM29LV800B in www.amd.com. Please send me the model. Thanks and RegardsArticle: 64309
Hi, there: I want to know whether the -bus_delimiter () work in XST.exe under ISE WebPack 4.2? Does a delimiter () work with my verilog source codes? In my design, I need to instantiate some vendor's NMC macros, in the macros, the bus delimiter is (). NGBuild gave me an error as follows: ERROR:NgdBuild:76 - File "D:\iir\iir/iir.nmc" cannot be merged into block "u_iir_0" (TYPE="iir") because one or more pins on the block, including pin "IN<3>", were not found in the file. Please make sure that all pins on the instantiated component match pins in the lower-level design block (irrespective of case). If there are bussed pins on this block, make sure that the upper-level and lower-level netlists use the same bus-naming convention. I could not find the "Bus demiliter" option in the Synthesize->Properties, so I used commandline mode. The XST.exe doesn't give me error for my -bus_delimiter () but it put it in "Other Options"...I wonder whether this option is working or not. Best Regards, KelvinArticle: 64311
Hi Dennis,
Dennis McCrohan <dennis.mccrohan@xilinx.com> wrote in message news:<3FE33379.AD00F1DE@xilinx.com>...
> > I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> > from different devices (e.g. a CPU), go through the cpld, and end on
> > the system's expansion bus. I need to derive the timings for all the
> > signals on this expansion bus, which depend on the timing of the
> > signals at the CPU and on the prop. delays of the cpld.
> >
> > The datasheet says this device has "predictable and deterministic
> > timing". What does this mean exactly?
>
> Umm, hmm, I think that may be marketing-speak for "not subject to
> variations in routing (wire) delay like those FPGAs".
oops.. then my approach to timing calculations will be wrong..
> > For example, take the pad to pad
> > delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> > a maximum value,
>
> Yup. See below.
>
> > or can I rely in the delay being 10 ns?
> >
> > e.g. take the following signal from the CPU:
> >
> > CE0# assert delay from rising edge of CLK: min 2 ns, typ 8 ns, max 10
> > ns.
> >
> > The CLK signal does not go through the cpld, but CE0# does. The timing
> > report indeed says propagation delay for CE0# is 10 ns. Can I assume
> > that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> > relative to the rising edge of CLK? Or are the figures specified by
> > xilinx _maximum_ times only?
> >
> > Thanks.
>
> Unless otherwise noted the times shown in the timing report or datahseet
> for our CPLDs would be worst-case values. That means the lowest allowable
> operating voltage, hottest allowable temperature, and a device built on a
> Friday before a holiday ;-)
:)
> . Assuming that you stay within the allowable
> operating conditions, no device that you get from Xilinx should exhibit
> worse delay behavior than this, and the vast majority will be faster.
I see.
But then there's something I don't quite understand. I looked at white
paper 122 from Xilinx, ("Using the CoolRunner XPLA3 Timing Model"). There
are several examples on how to derive the 'external' timing parameters
from the internal parameters. All of these examples seem to assume the
internal timing parameters are always fixed values. Take for example, Tsu
(setup time for data at pad to clock at pad). This is derived as follows:
Tsu = Tin + Tlogi + Tsui - Tgck
Tin = Input buffer delay (for data)
Tlogi = Internal logic delay
Tsui = Internal register setup time
Tgck = Global clock buffer delay
The XCR3256XL datasheet says that for a -10 device:
Tin = max 3.3 ns
Tlogi1 = max 2.5 ns (assuming single p-term)
Tsui = min 1.0 ns
Tgck = max 1.3 ns
And indeed the same datasheet says that for 1 p-term, Tsu is:
Tsu1 = 3.3 + 2.5 + 1 - 1.3 = min 5.5 ns
Now my question is this: If we must take all the internal timing values
as worst case values, then the above equation could be wrong. For example,
Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
Actually, the correct worst case equation should then be something like
this:
Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
With no known value for Tgck_min one would need to assume a minimum 0 ns
for this parameter, which would yield a worst case Tsu of 6.8 ns.
Isn't this correct?
Thanks for your help!
Guillermo Rodriguez
Article: 64312Hi all, I would like know from the experts if the following behavior is possible if the input signal rise is exeeded. Xilinx states in its datasheet it shall be no more than 250 ns. If it is for exemaple 350 ns, but still - single pole - monotonic rise time, what is the internal logic seeing? Is it possible that the transistion from "0-1" is being seen as something like "0-1-0-1", or is only a matter of power consumption in the CMOS input stage, or even something else? Best Regards MarkusArticle: 64313
Markus Meng wrote: > Hi all, > > I would like know from the experts if the following behavior is possible > if the input signal rise is exeeded. Xilinx states in its datasheet it shall > be > no more than 250 ns. > > If it is for exemaple 350 ns, but still - single pole - monotonic rise time, > what > is the internal logic seeing? Is it possible that the transistion > from "0-1" is being seen as something like "0-1-0-1", or is only a matter of > power consumption in the CMOS input stage, or even something else? Both. Slow slew IPs will certainly increase the power, due to more time in the linear region. They can also cause double clocking, and you can get some feel for this by adding some finite ground bounce. eg a 3.5V slev in 350ns is 10V/us, or 100mv in 10ns. Thus, if a consequent OP,( or many buried nodes ) change within 10ns, and this causes 100mv of ground movement, then you get double-clocking effects. Hysteresis will help, but does _not_ guarantee to eliminate this - it gives a threshold to the tolerable system bounce. Carefull design is still needed to ensure you stay comfortably under that. What Hysteresis _does_ reduce greatly, is threshold oscillation - the effect where the CMOS inverter chain actually oscillates whilst in the linear region - this oscillation is typ very fast, above the clock MAX, but it can cause strange effects in even 'unrelated' logic. Mention this to a digitial designer, and mostly you get a blank stare :) -jgArticle: 64314
"Markus Meng" <meng.engineering@bluewin.ch> wrote in message news:<3fede218_1@news.bluewin.ch>... > Hi all, > > I would like know from the experts if the following behavior is possible > if the input signal rise is exeeded. Xilinx states in its datasheet it shall > be > no more than 250 ns. > > If it is for exemaple 350 ns, but still - single pole - monotonic rise time, > what > is the internal logic seeing? Is it possible that the transistion > from "0-1" is being seen as something like "0-1-0-1", or is only a matter of > power consumption in the CMOS input stage, or even something else? > > Best Regards > Markus In the absence of noise ( if there were such a condition), there is no limit to the rise/fall time, but you would still have to face the large timing uncertainty. For combinatorial inputs, there never is a transition-time limit ( but you have to live with the timing uncertainty...) For clocks, any transition time of more than 10 ns is objectionable, since it can result in double-triggering caused by ground-bounce and general noise in the system (plus the timing uncertainty). The suspected increase in power consumption is really insignificant, less than 5 mA during less than 10% of the transition time. No big deal. Peter Alfke, Xilinx ApplicationsArticle: 64315
Guillermo, you are concerned about what we call "tracking".
Almost all timing specs are guaranteed max values.
The min time is not specified, and a conscientious engineer might be
tempted to assume zero.
In reality, it is impossible for a small piece of silicon to be
simultaneously slow and ultra-fast.
Years ago, I defined a tracking factor: If any parameter is actually
at its max value (it cannot be any longer), then all other timing
parameters are between 70% and 100% of their guaranteed max values.
But if the chip is inherently fast, and is cold, and has high Vcc,
then all delays will be short, but the above relationship still holds:
They all track with a max 30% error between them.
This method of calculating was unchallenged until recently, when some
of the FPGA parameters started using soghisticated compensation
techniques ( like in the DCM) and hardly changed at all, while the
traditional delays showed their ususal temperature dependence ( +0.35%
for ever degree C) and voltage dependence ( 1% faster for every 1%
increse in Vcc ).
These things cannot be guaranteed in writing, since there always are
exceptions (metal delays are more stable than transistor delays, etc),
but they can serve as a guideline. And they have done that over the
past fifteen years. (You can find these explanations in old Xilinx
data books prior to 1994.)
Peter Alfke, Xilinx Applications.
========================================
guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> Hi Dennis,
>
> Dennis McCrohan <dennis.mccrohan@xilinx.com> wrote in message news:<3FE33379.AD00F1DE@xilinx.com>...
> > > I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> > > from different devices (e.g. a CPU), go through the cpld, and end on
> > > the system's expansion bus. I need to derive the timings for all the
> > > signals on this expansion bus, which depend on the timing of the
> > > signals at the CPU and on the prop. delays of the cpld.
> > >
> > > The datasheet says this device has "predictable and deterministic
> > > timing". What does this mean exactly?
> >
> > Umm, hmm, I think that may be marketing-speak for "not subject to
> > variations in routing (wire) delay like those FPGAs".
>
> oops.. then my approach to timing calculations will be wrong..
>
> > > For example, take the pad to pad
> > > delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> > > a maximum value,
> >
> > Yup. See below.
> >
> > > or can I rely in the delay being 10 ns?
> > >
> > > e.g. take the following signal from the CPU:
> > >
> > > CE0# assert delay from rising edge of CLK: min 2 ns, typ 8 ns, max 10
> > > ns.
> > >
> > > The CLK signal does not go through the cpld, but CE0# does. The timing
> > > report indeed says propagation delay for CE0# is 10 ns. Can I assume
> > > that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> > > relative to the rising edge of CLK? Or are the figures specified by
> > > xilinx _maximum_ times only?
> > >
> > > Thanks.
> >
> > Unless otherwise noted the times shown in the timing report or datahseet
> > for our CPLDs would be worst-case values. That means the lowest allowable
> > operating voltage, hottest allowable temperature, and a device built on a
> > Friday before a holiday ;-)
>
> :)
>
> > . Assuming that you stay within the allowable
> > operating conditions, no device that you get from Xilinx should exhibit
> > worse delay behavior than this, and the vast majority will be faster.
>
> I see.
>
> But then there's something I don't quite understand. I looked at white
> paper 122 from Xilinx, ("Using the CoolRunner XPLA3 Timing Model"). There
> are several examples on how to derive the 'external' timing parameters
> from the internal parameters. All of these examples seem to assume the
> internal timing parameters are always fixed values. Take for example, Tsu
> (setup time for data at pad to clock at pad). This is derived as follows:
>
> Tsu = Tin + Tlogi + Tsui - Tgck
>
> Tin = Input buffer delay (for data)
> Tlogi = Internal logic delay
> Tsui = Internal register setup time
> Tgck = Global clock buffer delay
>
>
> The XCR3256XL datasheet says that for a -10 device:
>
> Tin = max 3.3 ns
> Tlogi1 = max 2.5 ns (assuming single p-term)
> Tsui = min 1.0 ns
> Tgck = max 1.3 ns
>
> And indeed the same datasheet says that for 1 p-term, Tsu is:
>
> Tsu1 = 3.3 + 2.5 + 1 - 1.3 = min 5.5 ns
>
>
> Now my question is this: If we must take all the internal timing values
> as worst case values, then the above equation could be wrong. For example,
> Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
>
> Actually, the correct worst case equation should then be something like
> this:
>
> Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
>
> With no known value for Tgck_min one would need to assume a minimum 0 ns
> for this parameter, which would yield a worst case Tsu of 6.8 ns.
>
> Isn't this correct?
>
> Thanks for your help!
>
> Guillermo Rodriguez
Article: 64316"Lost Temper" <305liuzg@163.net> writes: > I can't find the verilog model for AM29LV800B in www.amd.com. Try to find a compatible Fujitsu flash model at: http://www.fujitsu.com/services/microelectronics/product/memory/flash-sim-model/vhdl/casestudy_pdt-memory-flash-sim-vhdl_1.html AMD and Fujitsu flash are now called Spansion (www.spansion.com). Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 64317
guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>... > Now my question is this: If we must take all the internal timing values > as worst case values, then the above equation could be wrong. For example, > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns. > > Actually, the correct worst case equation should then be something like > this: > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min > > With no known value for Tgck_min one would need to assume a minimum 0 ns > for this parameter, which would yield a worst case Tsu of 6.8 ns. > > Isn't this correct? Perhaps it would be a worthwhile exercise to code up your CPLD, let the tools have at it, and see what the static timing analyzer says? --aArticle: 64318
Hi, "Marc" <damc4@gmx.de> wrote in message news:cf0ec8fc.0312210240.54c85860@posting.google.com... > Didn't you mean this OpenCores project? > > http://www.opencores.org/projects/ethmac/ > > It is an Ethernet MAC using the MII interface to connect to every PHY you want! > I used the core in Altera FPGAs and have had no problems with it. Which PHY did you use? I have LAN91C111 but don't know whether it can be used only as the PHY!? Regards > > Regards, > Marc > > e-mail: Marc dot Colling at MaCo-Engineering dot de > > > "John Retta" <jretta@rtc-inc.com> wrote in message news:<N2QDb.7879$0s2.2125@newsread2.news.pas.earthlink.net>... > > That is correct. No Phy. My mistake in original email. > > > > -- > > Regards, > > John Retta > > > > email : jretta@rtc-inc.com > > web : www.rtc-inc.com > > > > > > "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message > > news:3FDF7EEB.7060509@flukenetworks.com... > > > John Retta wrote: > > > > You can remove the cost variable from the equation. > > > > Check www.opencores.org. They offer open source code > > > > for numerous cores, including a MAC PHY > > > > > > I found the MAC, but the only PHY listed is for USB. > > > > > > > > > -- Mike Treseler > > >Article: 64319
Peter Alfke wrote: > In the absence of noise ( if there were such a condition), there is no > limit to the rise/fall time, but you would still have to face the > large timing uncertainty. > > For combinatorial inputs, there never is a transition-time limit ( but > you have to live with the timing uncertainty...) This is true only for an ideal (viz : non real, 0nH ) device. If transistion oscillations occur (and they are common on non schmitt, CMOS chained inverter structures), then even combin IPs can affect other seemingly unrelated logic. -jgArticle: 64320
Hi John, the LAN91C111 has an external MII interface and it seems to be possible to disable the internal PHY (and use this MII for an external PHY). If it works also the other way round I have no idea, never tried it. I used the folowing PHYs together with the OpenCores MAC: Broadcom BCM5201, AMD AM79C874 NetPHY, National Semi DP83865. What kind of hardware do you use? Regards, Marc e-mail: Marc dot Colling at MaCo-Engineering dot de "John" <305liuzg@163.net> wrote in message news:<bsm116$n39$1@mail.cn99.com>... > Hi, > "Marc" <damc4@gmx.de> wrote in message > news:cf0ec8fc.0312210240.54c85860@posting.google.com... > > Didn't you mean this OpenCores project? > > > > http://www.opencores.org/projects/ethmac/ > > > > It is an Ethernet MAC using the MII interface to connect to every PHY you > want! > > I used the core in Altera FPGAs and have had no problems with it. > > Which PHY did you use? > I have LAN91C111 but don't know whether it can be used only as the PHY!? > > Regards > > > > > Regards, > > Marc > > > > e-mail: Marc dot Colling at MaCo-Engineering dot de > > > > > > "John Retta" <jretta@rtc-inc.com> wrote in message > news:<N2QDb.7879$0s2.2125@newsread2.news.pas.earthlink.net>... > > > That is correct. No Phy. My mistake in original email. > > > > > > -- > > > Regards, > > > John Retta > > > > > > email : jretta@rtc-inc.com > > > web : www.rtc-inc.com > > > > > > > > > "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message > > > news:3FDF7EEB.7060509@flukenetworks.com... > > > > John Retta wrote: > > > > > You can remove the cost variable from the equation. > > > > > Check www.opencores.org. They offer open source code > > > > > for numerous cores, including a MAC PHY > > > > > > > > I found the MAC, but the only PHY listed is for USB. > > > > > > > > > > > > -- Mike Treseler > > > >Article: 64321
Hi I am working with Altera Nios Kit with LAN91C111! Regards "Marc" <damc4@gmx.de> wrote in message news:cf0ec8fc.0312280334.409afc93@posting.google.com... > Hi John, > > the LAN91C111 has an external MII interface and it seems to be > possible to disable the internal PHY (and use this MII for an external > PHY). If it works also the other way round I have no idea, never tried > it. > > I used the folowing PHYs MAC: Broatogether with the OpenCores dcom > BCM5201, AMD AM79C874 NetPHY, National Semi DP83865. > > What kind of hardware do you use? > > Regards, > Marc > > e-mail: Marc dot Colling at MaCo-Engineering dot de > > > > "John" <305liuzg@163.net> wrote in message news:<bsm116$n39$1@mail.cn99.com>... > > Hi, > > "Marc" <damc4@gmx.de> wrote in message > > news:cf0ec8fc.0312210240.54c85860@posting.google.com... > > > Didn't you mean this OpenCores project? > > > > > > http://www.opencores.org/projects/ethmac/ > > > > > > It is an Ethernet MAC using the MII interface to connect to every PHY you > > want! > > > I used the core in Altera FPGAs and have had no problems with it. > > > > Which PHY did you use? > > I have LAN91C111 but don't know whether it can be used only as the PHY!? > > > > Regards > > > > > > > > Regards, > > > Marc > > > > > > e-mail: Marc dot Colling at MaCo-Engineering dot de > > > > > > > > > "John Retta" <jretta@rtc-inc.com> wrote in message > > news:<N2QDb.7879$0s2.2125@newsread2.news.pas.earthlink.net>... > > > > That is correct. No Phy. My mistake in original email. > > > > > > > > -- > > > > Regards, > > > > John Retta > > > > > > > > email : jretta@rtc-inc.com > > > > web : www.rtc-inc.com > > > > > > > > > > > > "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message > > > > news:3FDF7EEB.7060509@flukenetworks.com... > > > > > John Retta wrote: > > > > > > You can remove the cost variable from the equation. > > > > > > Check www.opencores.org. They offer open source code > > > > > > for numerous cores, including a MAC PHY > > > > > > > > > > I found the MAC, but the only PHY listed is for USB. > > > > > > > > > > > > > > > -- Mike Treseler > > > > >Article: 64322
I'm doing a Virtex-II Pro design that uses DDR SDRAM SODIMM modules as data storage. There's a possibility (because DDR and DDR2 SODIMMs are footprint compatible) to support the upcoming DDR2 modules in this design too. Now, there's a problem: DDR2 SDRAM supports the use of differential signaling on data strobe lines (DQS). However, these signals are still 1.8V SSTL. Virtex-II Pro device (or maybe ISE software) seem not to support differential SSTL IO. So, the question is: do the specific hardware resources in Virtex-II Pro exist to support DDR2 differential IO, or, if not, that are the possible workarounds for this besides from just not using the DDR2 differential IO at all? Regards, BobArticle: 64323
All Xilinx FPGAs have input hysteresis (Schmitt triggered inputs). Peter Alfke jim granville <no.spam@designtools.co.nz> wrote in message news:<N%vHb.14744$ws.1502122@news02.tsnz.net>... > Peter Alfke wrote: > > In the absence of noise ( if there were such a condition), there is no > > limit to the rise/fall time, but you would still have to face the > > large timing uncertainty. > > > > For combinatorial inputs, there never is a transition-time limit ( but > > you have to live with the timing uncertainty...) > > This is true only for an ideal (viz : non real, 0nH ) device. > If transistion oscillations occur (and they are common on > non schmitt, CMOS chained inverter structures), then > even combin IPs can affect other seemingly unrelated logic. > > -jgArticle: 64324
Jarek wrote:
> How to simulate (observe) signals not connected to port (Xiilinx ISE
> WebPack-ModelSim XE).
> For example signal counter in project test.vhd.
To see the waveform "counter", try this:
vsim testbench -do "add wave sim:/testbench/uut/*; run 4 uS;"
To use "counter" in a testbench, you can package it,
or bring it out to a port,
or use modelsim signal spy.
-- Mike Treseler
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