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
I have a CPU register block where I use the outputs (wich are supposed to be static) to control other clock domains. The question rises; will these signals coming out of a flip-flop be guaranteed free for glitches? For a synchronous design, there is a setup&hold condition in the cpu clock domain where this signal will be stable, but how about the rest of the time window? Is there any tricks to make this guaranteed glitch free? The reason I ask is that I want to use this signal to mux (using 2 input muxcy to avoid lookup table glitches) a clock signal and I want the outgoing clk to be glitch-free. Maybe I have to route the switching signal thru a bidir pin and put a capacitor on it. Note:I WILL treat this new clk as a new clock domain, and the domain WILL be reset properly after switching clock.Article: 102326
GREAT LINK. I typically check your website and have used your forums a few times. In fact I asked a question about the JTAG stuff a while ago. I have compiled and tried playing around with your examples with a 4 device board I designed. I am going to try writing my own C app to test my boards. Your site is just what I was looking for. Anyone know of other C tutorials for writing your own JTAG apps? I would rather write my own than buy the really expensive commercial applications. matt "Jean Nicolle" <jean.nicolle@sbcglobal.net> wrote in message news:Um59g.4988$fb2.2761@newssvr27.news.prodigy.net... > Correct. > > I actually know only one flash that can be programmed through JTAG > (Platform flash, made by ST, sold by Xilinx). So I'm a little optimistic > in my webpage. > Anyone knows if we can get these flash from ST directly? or another > source? > > "Ad" <adam.taylor@eads.com> wrote in message > news:1147441764.754114.86100@d71g2000cwd.googlegroups.com... >> Eli >> >> most flash devices do not have a JTAG port but can still be programmed >> via JTAG by ensuring all the pins of the flash chip which are required >> address, data, and control signals are connected to a device which does >> have a boundary scan port. Unused fpag pins are good for this. The JTAG >> software can then control the FPGA pins connected to the flash to write >> data into the flash device. If you are going to do it this way it is >> often necessary to take the WE pin to a spare pin on the JTAG header to >> enable the speed of the programming to be quicker. >> >> hope this helps >> >> Ad >> > >Article: 102327
Hi, I have to establish a 50MHz serial communication with a Spartan3, so: 1) should I place termination resistors on data_in, data_out or clock pins? Value? 2) could I use somehow DCIs (I'm working with LVCMOS33 standard)? then on the pull-up/down: 3) which JTAG pins should I pull-up? With 10KOhms? 4) I'll need to use serial mode (slave or master) also on the configuration stage, so I could harware fix the mode pins as I'll always be able to connect with the JTAG, no matter how the pins mode are set, right? Thanks, MarcoArticle: 102328
YiQi wrote: > In a FPGA, does a latch and a memory cell make any different? Isn't it > the same ? In most FPGAs there are no latches. You should avoid inferring latches in these FPGAs, because they are created out of logic gates. Black-RAM in FPGAs can often be accessed using the edge of a signal. -> No Latches. For standard cells you may use latches to get a compatible behavior to standard DRAM. DRAM is one capacitor and one transistor. Latches are closed loops build out of logic gates. RalfArticle: 102329
3) usually doesnt matter at all 4) yes and no. JTAG config overrides the mode settings, but there are cases where JTAG configuration fails unless tricks are made (changing mode as example). Basically there is some 'critical time slot' in the JTAG config sequence, if in that time the FPGA sees a valid SYNC on serial config then the JTAG config gets confused and weird things happen (can happen). AnttiArticle: 102330
Marco The need for termination resistor depends upon alot of things, though it is not that complicated. you will need to terminate the signal if the rise time divided by the propagation speed (rise time / propagation speed) is greater than one sixth of the pcb track length (different people may use different ratios but i will stick with what i learnt and know to work). the termination resistor value will depend upon the track imedance, when laying out the pcb try and ensure the tracks all have same impedance regardless of the layer they are on (this involves varying the trace widths on different layers during layout). You then have a choice of termination schemes A.C termination is good and can save power, while series (source) termination is also useful. There are packagesavailable that will determine if you need termiantion for your traces hyperlinx is one of the best. If you are ussure you could always add the pads and not fit the resistors, it easier that way hope this helps AdArticle: 102331
"srini" <g.shrinivasan@gmail.com> wrote:
>I am using Viretx II as my target FPGA. I use Synplify Pro 8.4 for
>synthesis and Xilinx ISE 7.1 for PAR. All my input/ouput data are
>registered. Do I have to specify the IO delays in the constraints
>editor in Synplify Pro? Even if I have to specify the IO delays, I dont
>have any idea as to what values should be given. Any thumb rules to
>start with?
Synthesis constraints are needed to give information to the synthesis
tools to allow it to generate a reasonable implementation of your
design. If all inputs/outputs are in registers in the IOB, there
should be no need for synthesis timing constraints on inputs/outputs.
To avoid confusion, probably best to turn off forward annotation of
timing constraints (or delete the .ncf file after synthesis).
>Similarly, there is a OFFSET IN/OUT constraint in the Xilinx
>constrainst editor. Right now I have left it untouched bcoz I dont know
>what values are normally given for it. In my PAR report, I am seeing
>the maxilum pin delay to be some 8.6 ns. Has it got something to do
>with the OFFSET IN or setup time constraint? Can anyone clear my doubts
>and help in specifying the setup/hold times?
What does your system require? For an input, where is the input
coming from? Is it on the same clock, or a clock with a timing
relationship to the FPGA register clock? If so, then do a calculation
something like the following:
Required setup time = (clock period)
- (external part clock to out)
- (trace delay 80 ps/cm)
My personal habit is to document all of the timing calculations in the
.ucf file as comments. Open it as a text file and type in something
like this:
#
###############################################################################
#
# Data blah blah blah Output Requirement
#
# Calculate foo to blah
# Based on rev 11.2 of Some Semiconductor Company's Part
# Clock Period = 10.4 ns
# foobar output (Spec reference) = (1.4 ns + 0.15 ns/pf)
# Fanout = 3, estimate cap = 15 pf = (1.4 ns + 0.8 ns)
# = 2.2 ns
# Data (from blah) = 1/2 clk + Yahda = 5.2 ns + 2.2 ns
# = 6.4 ns
# Trace delay = 80ps/cm * 12 cm = 0.96 ns
#
# Allowed time = Clock period - (Foobar) - (Yahda) - Trace
# = 10.4 ns - 2.2 ns - 6.4 ns - 0.96 ns
# = 3.77 ns
# Note: This assumes jitter isn't a factor
#
INST "SOMEPINS<*>" TNM = "DUT_OUT_GRP";
#
TIMEGRP "DUT_OUT_GRP" OFFSET = OUT 3.77 NS AFTER "NAME_OF_CLOCK";
#
#########################################################################
The example is made up, of course. If it was real, I would have
checked and rechecked any math, checked and recheck the specification
references, and tried to make sure that it was easy to understand.
To make sure that an input with no external timing requirements is in
the IOB, I do something like this:
#########################################################################
#
# Data from FOO inputs
# These pins should be registered in the IOB FFs. This timespec
# checks that this is correct.
# Data sheet registered time = 1.1 ns
#
INST "FOO<*>" TNM = "FOO_IN_GRP";
#
TIMEGRP "FOO_IN_GRP" OFFSET = IN 1.2 NS BEFORE "CLOCK";
#
#########################################################################
Look in the data sheet for the registered setup or clock to output
time is. Remember to adjust for IO standard, and for any DCM or PLL
settings.
--
Phil Hays
Article: 102332rickman wrote: > But I think the OP is saying the values selected provide a voltage 40 > mV too high. Yes, I am still on the drawing board at this point. > Or are you talking about the TI app notes? I am, I haven't found any Xilinx app notes about the part. Are there any? > Actually I don't see how > you can say all three outputs are 40 mV too high when the 1.2 volt > output does not use external resistors! Good point, my mistake. Sorry. Both Buck 2 and the LDO are approx 40mV too high. > The values in the TI data > sheet (figure 1) produce about 2.54 volts, 3.29 volts and of course, > 1.2 volts. I am indeed. I am probably being stupid, but using the values in all the TI example circuits (I have about 5 variations here) the Buck 2 potential divider uses values of 61K9 and 36K5 (or 319K and 365K). By equation 15 in the TI datasheet these values give a Vout of 3.343V. Similarly, for the LDO the value 2.545V. These are 43mV and 45mV over spec respectively. Now, it is extremely likely that I am either worrying about nothing, or being very stupid. Is this over-voltage specified deliberately, or is it simply a product of using nearest-fit resistor values? Or have I done my calculations badly? If you can clarify that for me I would be very grateful. Best, -- PeterArticle: 102333
Aurelian Lazarut wrote: > Is your voltmeter calibrated? > Aurash My design-time voltmeter (i.e. my calculator) is well calibrated :) I'm still on paper at this point. But thanks for the suggestion nevertheless. -- PeterArticle: 102334
Antti, 3) why it doesn't matter? I saw several schemes with pull-ups, sometimes with different configurations (someone placed on TCK and TMS, others on TDI... that's why I ask) 4) for the prototype I should go with a 3-element-dip-switch toward GND to be safe? Ad, I think I'll place on the 3 pins a 0 Ohm resistance and I'll replace it with a 22 Ohm or other values if I'll see I need it. Do you agree? Would you place terminations only on 1 or 2 of these 3 pins? Thanks, MarcoArticle: 102335
Given the effect is on both supplies I would particularly look at anything common like the reference voltage or a common resistor value. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in message news:e49ql2$pa6$1@dux.dundee.ac.uk... > John, > > Thanks for your response. It think I have the resistor values correct, > I've attempted to follow the app notes to the letter, anyway. Resistor > and Vref tolerances is a good idea, I should have checked that before I > posted. Having looked at them, it could possibly be the source of the > 40mV. If it were required that near the lowest error tolerance bound the > Vref was still not below the required value, this would seem make some > sense. The only niggle is that the error bounds are relative > (resistor/Vref), and this 40mV over-voltage doesn't change all that much > from the 1.2V to the 3.3V supplies. The app notes don't seem to provide > an explanation for this. > > I have come up with two plans, one for a voltage close to spec, another > for 40mV (approx) over. Unless I hear any different, I'll probably > prototype with the former, and only use the latter if things go belly-up. > > From your experience, do you have any other advice about using these > devices? > > Thanks, > > -- Peter > > John Adair wrote: >> Be careful of the resistor values. We have used these parts and from my >> memory the LDO has a different reference voltage and hence resistor ratio >> to the switcher elements. Your 40mV could be resistor or reference >> tolerance have you checked those? >> >> John Adair >> Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan3 Development >> Board. >> http://www.enterpoint.co.uk >> >> "Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote >> in >>> I hope this isn't OT but I was wondering if anyone has any experience >>> using the TPS75003 to power a Spartan 3? For my particular application >>> I'm having to swap round the output voltages produced by one of the buck >>> convertors and the LDO with respect to most of the app notes. The >>> potential dividers which give the reference feedback in the app notes >>> come out to give a voltage which is consistently about 40mV above spec >>> for all three outputs. I was wondering if anyone knew why? Or is it >>> just a bit of design headroom? >Article: 102336
Thanks for all the help everyone and the references.Article: 102337
Marco wrote: > Antti, > 3) why it doesn't matter? I saw several schemes with pull-ups, > sometimes with different configurations (someone placed on TCK and TMS, > others on TDI... that's why I ask) > 4) for the prototype I should go with a 3-element-dip-switch toward GND > to be safe? > > Ad, > I think I'll place on the 3 pins a 0 Ohm resistance and I'll replace it > with a 22 Ohm or other values if I'll see I need it. Do you agree? > Would you place terminations only on 1 or 2 of these 3 pins? > > Thanks, > Marco Marco placing the 0 ohm links is a good idea make sure you place them correctly for source termination these resistors should be placed inline with the signal and near the output driver, for ac termination the resistors need to be placed near the destination of the signal to ensure you get the correct resistor / schematic i would suggest a quick google search on termination schemes. regards AdArticle: 102338
I am interested in any FPGA cores that implement the IEEE-1394a FireWire interface. The application is to process images from several FireWire digital cameras in a hand gesture recognition system. Our current plan is to dedicate a computer to this task, but it may only be able to handle 3-4 cameras (we want to have as many as 8, meaning we may need 3 computers). The actual processing is quite simple and could be done by a single FPGA. So far I have found a core from Altera that does what I need, but I would prefer a Xilinx core. Any ideas? Tom Seim Pacific Northwest National Laboratory Richland, WAArticle: 102339
Two slices per CLB, four 6-LUTs + 4 FFs per slice. A LUT can be
configured as a RAM64 or SRL32. But a CLB can only have 4 RAMs or SRLs
(similar to SLICEL / SLICEM). DSP blocks have a 25x18 multiplier
(useful for 32-bit floating point). Block RAMs are 36 kbits.
Press release says engineering samples of LX50, lX85, LX110 are
shipping now.
LX50:
7,200 slices (actual slices, CLB array 120*30)
48 BRAMs (each 36kbits, total 1728 kbits)
48 DSP
FF324, FF676, FF1153
LX85:
12,960 slices
96 BRAMs
48 DSP
FF676, FF1153
LX110:
17,280 slices
129 BRAMs
64 DSP
FF676, FF1153, FF1760
Press release
http://www.xilinx.com/prs_rls/2006/silicon_vir/0658lxship.htm
Slice schematics, some timing numbers and performance figures (PDF)
http://www.xilinx.com/bvdocs/whitepapers/wp245.pdf
Product table, (slice/bram/dsp/io counts for each LX-series part) (PDF)
http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex5/Virtex-5_LX_Product_Table.pdf
Comparison with Virtex-4
http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex5/overview/v5v4features.htm
Article: 102340
Hi everyone,
I've followed the instructions from John Williams and Jason Wu, and
finally got uClinux-kernel booted on my Spartan-3E-Starter-Kit
(http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-SK-US).
However, there's no boot message on the terminal, I got just a login
prompt when the kernel started:
uclinux-auto login:
Anyway, the kernel still works.
Then I tried to test the networking and followed the instructions here
(http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/Documentation/networking.html).
There's no problem to ping it self. But I can't ping my PC, which is
connected to the Eva-Board using crossover cable. There's even no ARP
packets received.
It seems that the RX- and TX-pins are not connected to the FPGA. Did I
miss something?
Any help is appreciated.
Qichen
PS:
The auto-config.in is generated by EDK Libgen (8.1 sp2) and directly
copied to
uClinux-dist/linux-2.4.x/arch/microblaze/platform/uclinux-auto/
The eth0 settings are as follows:
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:C0:A3:E5:44
inet addr:192.168.1.4 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packeckts:0 errors:0 dropped:0 overruns:0 frame:0
TX packeckts:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
Interrupt:2
The section of opb_ethernet in the system.mhs is as follows:
BEGIN opb_ethernet
PARAMETER INSTANCE = Ethernet_MAC
PARAMETER HW_VER = 1.04.a
PARAMETER C_DMA_PRESENT = 1
PARAMETER C_IPIF_RDFIFO_DEPTH = 32768
PARAMETER C_IPIF_WRFIFO_DEPTH = 32768
PARAMETER C_OPB_CLK_PERIOD_PS = 20000
PARAMETER C_BASEADDR = 0x40c00000
PARAMETER C_HIGHADDR = 0x40c0ffff
BUS_INTERFACE SOPB = mb_opb
PORT OPB_Clk = sys_clk_s
PORT PHY_tx_clk = fpga_0_Ethernet_MAC_PHY_tx_clk
PORT PHY_rx_clk = fpga_0_Ethernet_MAC_PHY_rx_clk
PORT PHY_crs = fpga_0_Ethernet_MAC_PHY_crs
PORT PHY_dv = fpga_0_Ethernet_MAC_PHY_dv
PORT PHY_rx_data = fpga_0_Ethernet_MAC_PHY_rx_data
PORT PHY_col = fpga_0_Ethernet_MAC_PHY_col
PORT PHY_rx_er = fpga_0_Ethernet_MAC_PHY_rx_er
PORT PHY_tx_en = fpga_0_Ethernet_MAC_PHY_tx_en
PORT PHY_tx_data = fpga_0_Ethernet_MAC_PHY_tx_data
PORT PHY_Mii_clk = fpga_0_Ethernet_MAC_PHY_Mii_clk
PORT PHY_Mii_data = fpga_0_Ethernet_MAC_PHY_Mii_data
PORT IP2INTC_Irpt = Ethernet_MAC_IP2INTC_Irpt
END
Article: 102341I am looking for someone who can help me with an old design. THis was done with a XC4005 and of course none of the new tools support this part. I have an old Foundation CD v2.1i and insalled it on an old win 98 machine but cannot get the synopsys license to work. So looking for help OR if someone out there still has a working software and can build me a prom file please contact me and we can come to some arrangement ($$$). Paul LowsonArticle: 102342
On Mon, 15 May 2006 13:02:43 +0100, Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote: >John, > >Thanks for your response. It think I have the resistor values correct, >I've attempted to follow the app notes to the letter, anyway. Resistor >and Vref tolerances is a good idea, I should have checked that before I >posted. Having looked at them, it could possibly be the source of the >40mV. If it were required that near the lowest error tolerance bound >the Vref was still not below the required value, this would seem make >some sense. The only niggle is that the error bounds are relative >(resistor/Vref), and this 40mV over-voltage doesn't change all that much >from the 1.2V to the 3.3V supplies. The app notes don't seem to provide >an explanation for this. > >I have come up with two plans, one for a voltage close to spec, another >for 40mV (approx) over. Unless I hear any different, I'll probably >prototype with the former, and only use the latter if things go belly-up. > > From your experience, do you have any other advice about using these >devices? > >Thanks, > >-- Peter > >John Adair wrote: >> Be careful of the resistor values. We have used these parts and from my >> memory the LDO has a different reference voltage and hence resistor ratio to >> the switcher elements. Your 40mV could be resistor or reference tolerance >> have you checked those? >> >> John Adair >> Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan3 Development Board. >> http://www.enterpoint.co.uk >> >> "Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in >>> I hope this isn't OT but I was wondering if anyone has any experience >>> using the TPS75003 to power a Spartan 3? For my particular application >>> I'm having to swap round the output voltages produced by one of the buck >>> convertors and the LDO with respect to most of the app notes. The >>> potential dividers which give the reference feedback in the app notes come >>> out to give a voltage which is consistently about 40mV above spec for all >>> three outputs. I was wondering if anyone knew why? Or is it just a bit >>> of design headroom? I would say that it is better to err slightly on the high side to compensate for IR drop between the regulator and the part. Once you build the prototype you can measure the actual drop (both ground and high sides) and tweak your values accordingly. I have used the TPS75003 in a ceramic capacitor configuration, because tantalum and small electrolytic capacitors are prohibited in our applications. In this case the divider network has to be designed differently to provide AC feedback from the switch. I asked TI about this, and they recommended that I follow the guidance in the TPS64200 datasheet (see figure 27 and associated discussion). This has worked well. ================================ Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 102343
I have just been ask to upgrade an old product which uses a XC4010 and a 4005. I know that these parts are not supported by Xilinx any more so my Q is does any one know if an other fpga That will fit in same footprint?? The 4005 is a 100p and the 4010 is a 16pin I was unable to find any thing or is there another solution?? This design was done with FPGA Express VHDL (at least thats what the web tools say) PaulArticle: 102344
Hi Peter.
part1::: I tried to use my system.ace file to boot and load the linux
root file system from the microdrive shipped with the ml300. The linux
boots up but when loading the rootfile system from the micro drive it
gives me an error saying that "cannot find /dev/xsysace/..part3 or
00.00. specify a correct root= option".
In my zImage.elf i had included the xsysace support and in the command
line i used the same command as Xilinx uses
"root=/dev/xsysace/disc0/part3".
-----------------------------------------------------------------------------------------------------------
part 2::: I treid to use the linux sample the xilinx provided, it boots
up well and i logged in as root. I setup the eth0 address of the board
as 192.168.0.10,
with default gateway as 192.168.0.1 and
subnet mask as 255.255.255.0
On my computer i setup the second nic card (eth1) as 192.168.0.1,
subnet mask as 255.255.255.0. the ifconfig looks like this
eth1 Link encap:Ethernet HWaddr 00:10:B5:F9:72:5B
inet addr:192.168.0.1 Bcast:192.168.0.255
Mask:255.255.255.0
inet6 addr: fe80::210:b5ff:fef9:725b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:63 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24948 (24.3 Kb) TX bytes:2308 (2.2 Kb)
Interrupt:10 Base address:0xb800
Now when i tried to mount a directory from my computer to the board
using nfs using the following command on the board it gies the error
command""
mount -t nfs 192.168.0.1:/opt/ml300_rootfs /pub
note: /opt/ml300_rootfs is in computer and /pub directory is on board.
error"
mount:RPC:Unable to receive;errno=connection refused
With warm regards,
Chakra.
Article: 102345ryanrs, Yup. Now Peter and I are able to talk about Virtex 5. Any questions? 65nm lives....both fabs! Of course, it is early, but we are in ES sampling, and accepting folks for early adoption. The release of the documention should be pretty good. I'd like to hear back on how good folks think it is. Austin ryanrs wrote: > Two slices per CLB, four 6-LUTs + 4 FFs per slice. A LUT can be > configured as a RAM64 or SRL32. But a CLB can only have 4 RAMs or SRLs > (similar to SLICEL / SLICEM). DSP blocks have a 25x18 multiplier > (useful for 32-bit floating point). Block RAMs are 36 kbits. > > Press release says engineering samples of LX50, lX85, LX110 are > shipping now. > > LX50: > 7,200 slices (actual slices, CLB array 120*30) > 48 BRAMs (each 36kbits, total 1728 kbits) > 48 DSP > FF324, FF676, FF1153 > > LX85: > 12,960 slices > 96 BRAMs > 48 DSP > FF676, FF1153 > > LX110: > 17,280 slices > 129 BRAMs > 64 DSP > FF676, FF1153, FF1760 > > Press release > http://www.xilinx.com/prs_rls/2006/silicon_vir/0658lxship.htm > > Slice schematics, some timing numbers and performance figures (PDF) > http://www.xilinx.com/bvdocs/whitepapers/wp245.pdf > > Product table, (slice/bram/dsp/io counts for each LX-series part) (PDF) > http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex5/Virtex-5_LX_Product_Table.pdf > > Comparison with Virtex-4 > http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex5/overview/v5v4features.htm >Article: 102346
Morten Leikvoll schrieb: > I have a CPU register block where I use the outputs (wich are supposed to be > static) to control other clock domains. > > The question rises; will these signals coming out of a flip-flop be > guaranteed free for glitches? The output of a flipflop is always glitch free (when setup and hold times are met) > For a synchronous design, there is a setup&hold condition in the cpu clock > domain where this signal will be stable, but how about the rest of the time > window? Is there any tricks to make this guaranteed glitch free? > > The reason I ask is that I want to use this signal to mux (using 2 input > muxcy to avoid lookup table glitches) a clock signal and I want the outgoing > clk to be glitch-free. Maybe I have to route the switching signal thru a This is another problem. In a tecXcluse a long time ago there was a glitch free clock MUX. They are also as hard macros in Virtex-II / Spartan 3 etc. > bidir pin and put a capacitor on it. Autsch. Dont do this! This is just a crude work around for, hmmmm,. Dont do it! Regards FalkArticle: 102347
On Mon, 15 May 2006 09:49:53 -0700, Austin Lesea wrote: > ryanrs, > > Yup. Now Peter and I are able to talk about Virtex 5. > > Any questions? > > 65nm lives....both fabs! > > Of course, it is early, but we are in ES sampling, and accepting folks for > early adoption. > > The release of the documention should be pretty good. I'd like to hear > back on how good folks think it is. > > Austin > > I don't see any mention of a V5FX on your website. Can you tell us anything about the RocketIO on the Virtex5-FX yet?Article: 102348
On Mon, 15 May 2006 09:47:50 -0700, Paul wrote: > I have just been ask to upgrade an old product which uses a XC4010 and a > 4005. I know that these parts are not supported by Xilinx any more so my Q > is does any one know if an other fpga That will fit in same footprint?? > The 4005 is a 100p and the 4010 is a 16pin I was unable to find any thing > or is there another solution?? > > This design was done with FPGA Express VHDL (at least thats what the web > tools say) > > > Paul The 4000 series were 5V only parts so you aren't going to find a modern part that fits into their footprint. If you have the VHDL from the original design you shouldn't have a lot of trouble consolidating most of the board into a single Spartan3, but of course you'll have to do a new board.Article: 102349
Josh, Always ask for what we didn't release? OK, that is fair. I wasn't very specific. Details on FX in June. For now, questions on LX. Austin Josh Rosen wrote: > On Mon, 15 May 2006 09:49:53 -0700, Austin Lesea wrote: > > >>ryanrs, >> >>Yup. Now Peter and I are able to talk about Virtex 5. >> >>Any questions? >> >>65nm lives....both fabs! >> >>Of course, it is early, but we are in ES sampling, and accepting folks for >>early adoption. >> >>The release of the documention should be pretty good. I'd like to hear >>back on how good folks think it is. >> >>Austin >> >> > > > I don't see any mention of a V5FX on your website. Can you tell us > anything about the RocketIO on the Virtex5-FX yet? > >
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