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
mohan wrote: > Can i programme non-xilinx fpga through xilinx impact tool & by using > xilinx parrellel four cable? You should be able to if you have an SVF or similar file. Then Impact is just playing back stuff rather than knowing anything special about the device. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 118501
Adam's project presentation at FCCM was great ... an async ring counter that actually changes speed when he freeze spray'ed it :) Great intro into delay insensitive async FPGA programming benefits ... better speed than clocked, and dynamically adjusts for logic speed. awesome intro project for AMTEL parts too ... John On Apr 27, 12:44 am, Adam Megacz <meg...@cs.berkeley.edu> wrote: > Hey all, > > I still have one more slipway board left over to give away; email me > if you want it and I'll mail it to you. > > If you don't know what I'm talking about, this might help: > > http://research.cs.berkeley.edu/project/slipway/ > > Please don't laugh at my pathetic PCB design skills. > > I also have two bare PCB's if anybody wants those. The components to > populate them run about $40 from DigiKey+Mouser and it's all easy > through-hole stuff. > > Thanks again to everybody who provided feedback and input at the > conference! Next year's project is well on its way... > > - aArticle: 118502
In article <f0mve4$mt2$5@aioe.org>, eric <erixx@gmx.net> wrote: > i'd like to have some informations about image compression on FPGA > hardware. Do you have some experiences with the Matrox Solios > and in special the version with the Altera FPGA? > I need some informations how much time it could take to implement > compression algorithms on FPGA and how to get an idea how many gates > are needed. Are there other solution than the one from Matrox? Elphel has an open-source FPGA-based camera system. I believe it does compression. You can grab their source from their website http://www.elphel.com -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 118503
Hi, Has anyone tried bridging the TS201 TigerSHARC with the PLX 9656 device? I'm trying to implement this in a current project and need details. The bridging is done via an Altera FPGA which also has to have custom logic for other functions such as Ethernet, sFPDP,etc. I know that the TS201 core runs at 600 MHz and the I/O bus at around 83.5 MHz. But at what speed does the PLX 9656 local bus run? Can the TS201 be connected directly to the PLX chip? Are there anyother alternatives to the PLX chip?Article: 118504
On Apr 28, 1:01 am, "Alvin Andries" <Alvin_Andries.no_s...@no.spam.versateladsl.be> wrote: > "MNiegl" <Michael.Ni...@cern.ch> wrote in message > > news:1177698983.194188.262100@o40g2000prh.googlegroups.com... > > > > > On Apr 27, 8:22 pm, Austin Lesea <aus...@xilinx.com> wrote: > > > MNiegl, > > > > Well, it seems that if you are doing everything right, and it worked > > > last time at 160 MHz, it has no excuse but to work this time. > > > > When I am faced with these kinds of problems, I go back and check > > > absolutely everything: it is likely the mistake is right there in front > > > of you, and you are not seeing it. > > > > Have you looked at the DCM in FPGA Editor? Sometimes you immediately > > > see that the code you wrote is doing exactly what it is supposed to (and > > > not what you want). > > > > Peter is fond of saying, "when your car dies on the road, do you first > > > check to see if the spark plug gap is correct? No, you check the most > > > likely cause - are you out of gas..." > > > > Austin > > > > > Hi everyone, > > > Hi Austin, > > > Actually, at the moment I'm heavily banking on my own stupidity and > > hope that it's only one small mistake I just can't find. > > Until now I only checked the DCM locations in FPGA Editor, I'll look > > at that some more intensively. > > And I love that quote from Peter, it's so true but sometimes so hard > > to obey. > > > Cheers, > > Michael > > Michael, > > Do you reset the second DCM after the first one has locked (a disturbed DCM > doesn't get to it's senses without some help)? > I agree that 2 DCMs in parallel would be better in this case, you only have > to calculate the phase offset for the second one. > > Alvin. Yes, I use the inverted Lock output of the first one to reset the second one. I even inserted a SRL16 in between as suggested by Xilinx in an Answer Record to have a bit of a delay in there. About the parallel implementation, I'd be more than happy to use it if anyone has an idea for an easy implementation of a stable 90 degree phase shift. Cheers, MichaelArticle: 118505
Francesco <francesco_poderico@yahoo.com> writes: > I'm trying to move my domain from my old provider to a newone (cheap) > Don't know why ... but this operation seems impossible because my > hosting has expired before I ask to transfer my domain??? Once a domain is actually expired, you have to renew it with the original registrar before you can transfer to a new registrar. And after you renew it, I think you have to wait a while (30 days? 90 days?) before you can transfer it. I'm not sure why. The transfer will involve renewing it for an additional year.Article: 118506
Hi I do have have plenty of Xilinx development hardware. I did thinkt hat for sure enough that i can pick up some board for almost any task. Now I just wanted to check out the Xilinx standard webserver demo, should be easy i did think. Ok first I picked up Memec/Avnet Spartan3 Microblaze Board. This i have used before, and it used to work. But the Avnet reference design is made for EDK 8.1, after update to EDK 8.2 the DDR memory did not work anymore. Oh, well this is not so recent board, they have not updated the design to pass memory test with EDK 8.2, so what lets take some more recent development board. Then all should work? So I startup the Spartan-3A Board.. goto Xilinx website to download the EDK reference designs. I look and I look I and I get upset more and more... There are NO REFERENCE designs for the Spartan-3A board!!!! Except some picoblaze thingies that are currently of zero interest for me. So I am still short of development boards? Which one should I try next? Memec VP20 board? Some Xilinx or Digilent board? I think Digilent S3E board would have working reference design, but this board I dont have. Disappointed really. Not to mention that the S3A board was supposed to be fully preloaded with demos, but all I see is led chaser. And when I plug the USB cable WinXP asks me to insert Xilinx installation disk, what isnt included in the package. Xilinx platform cable drivers are all installed so it should all work without "installation disk", but now it does not. Antti Who really doesnt want to troubleshoot "small things that Xilinx and related vendors just forget..." Sure I will now try to make the EDK design for S3A board myself, but should the DDR2 IP core not work out of the box on the S3A board, then I will be way more ..... I have DDR2 experience with Xilinx FPGA's... should it not want to work on S3A, I really dont want to seek down the issues. If Digilent is offering a low cost board with DDR2 memory, then there should be also at least ONE working design demonstrating the EDK DDR2 IP core use with S3AArticle: 118507
On 28 Apr., 05:46, fpga_t...@yahoo.com wrote: > Adam's project presentation at FCCM was great ... an async ring > counter that actually changes speed when he freeze spray'ed it :) > Great intro into delay insensitive async FPGA programming benefits ... > better speed than clocked, and dynamically adjusts for logic speed. I once used code density tests to measured how the delay of a spartan-2 carry chain changes during a clock cycle due to ground bounce. Fun stuff. Surprisingly simple for high resolution measurements in the 20GHz range. Kolja SulimmaArticle: 118508
"MNiegl" <Michael.Niegl@cern.ch> wrote in message news:1177697266.037429.124990@n35g2000prd.googlegroups.com... > Hi everyone, > > I have a problem that is bugging me for 2 days now and I was hoping > someone here might be able to help me out. > The problem is as follows: > still doesn't work!! > So after about 20 hours of trying I just ran out of ideas. Maybe > someone of you has another idea. > > Cheers, > Michael > Hi Michael, Can you reset the first DCM once everything has settled down after config? It might not be locking 'properly' at the first power on. Cheers, Syms. p.s. Peter's saying reminds me of No. 19. in the "You are wrong because" series. Reaching Bizarre Conclusions Without Any Information: Example: The car won't start. I'm certain the spark plugs have been stolen by rogue clowns.Article: 118509
Hello For research work, my goal is to estimate the ASIC-equivalent AREA in terms of [um^2] of my design implemented in Virtex-II Pro. As an example, V2P30 implementation is that 2500 LUTs, 3000 slices, 700 FFs, 0 BRAMs, I am trying to approxiate "LUT utilization" x "Die size" (1) or "Individual LUT physical size" x "Number of utilized LUTs" (2) as an ASIC-equivalent AREA. Equation (1) is over-simplification. Equation (2) is not considering wire utilization and other logic utilization. I need comment from experienced one. Thank you in advance.Article: 118510
On Apr 27, 5:49 pm, "M. Hamed" <mhs...@gmail.com> wrote: > I have two pin one is IN and the other is INOUT and they each one goes > to the D input of two FFs clocked by two different clocks Clk1, Clk2. > When I start the PAR process, Xilinx tool complains with the following > error: > > ERROR:Place:17 - The placement constraints of the IOBs sck and sdi > makes this design unroutable due to a physical routing limitation. > This device has a shared routing resource connecting the ICLK and > OTCLK pins on pairs of IOBs. This restriction means that these pairs > of pins must be driven by the same signal or one of the signals will > be unroutable. Before continuing please remove the placement > constraints or move one of these IOBs to a new location. > > The strange thing is that after looking at the design in the FPGA > editor, IOBs OTCLK are not used at all in the mentioned IOBs and for > one of the pins, the tool is using the internal FFs in the IOB while > in the other it's using only an input buffer and that feeds a FF in > another slice. > > Ofcourse removing the pin placement constraint fixes the problem but > that is something that cannot be done for the time being. > > I wonder if somebody can help me figure out what's going on. > > I'm using ISE 9.1.03i with Spartan 3 > > Thank you. You can't change the architecture of the chip. I ran into this same problem in Virtex 2. Each IOB seems to have two clock inputs that go to the two clocks of the DDR input and output flip-flops, and even if you use the same clock for both (rising edge and falling edge of the same wire) both routing resources are used (wires from the global routing to the IOB. You have to dig a bit deep in the datasheet to find it, but pairs of IOB's (the same pairs labeled as "N" and "P" halves of a differential pair) share only two wires to bring in these two clocks. If both IOB's are using only single data rate flip-flops, the two wires allow them to be pretty much independent of eachother. However when at least one has DDR flip-flops, the two IOB's need to share clock routing. Thus in a DDR SDRAM design for example you can't place a DQ pin and a DQS pin in two halves of a differential pair. The synthesis tool has apparently worked around this issue in your case by using fabric flip-flops for one of the two IOB's. If you can't change the pin location in your current design, the best you can do is to LOC the fabric slice where these flip-flops will end up. In the package pin listings from Xilinx there is a column showing the location of the nearest (from a routing perspective) slice to each IOB. HTH, Gabor PS read the section in the datasheet (ds099) titled "Double-Data-Rate Transmission" in the IOBs functional description. This is p. 13 in my copy which may not be the latest version. The paragraph starting "Some adjacent I/O blocks . . ." describes this.Article: 118511
This is the way I make arbiters:
// Concise priority arbiter
input [26:0] req; // Bit zero is highest priority
wire [26:0] gnt = req & -req; // Isolate least significant set bit
Since this method uses fast carry logic, it's quite fast- the best win is in
FPGAs, where the carry chain is much faster than regular routing. If you
can do a 32-bit add in one cycle, you can certainly do a 27-bit priority
arbiter. With ASICs or fully custom, you can pick the carry lookahead method
of your choice. Notice also that it is very easy to parameterize.
It's not hard to make a full round-robin arbiter out of this:
reg [26:0] prev; // Previous winner (saved from last cycle)
wire [26:0] req1 = req & ~((prev - 1) | prev); // Mask off previous winners
wire [26:0] gnt1 = req1 & -req1; // Select new winner
wire [26:0] winner = |gnt1 ? gnt1 : gnt; // Start from bit zero if none
// Save previous winner
always @(posedge clk) if (winner) prev <= winner;
The idea is that this expression converts from "one-hot" coding to
"thermometer" coding: ((x-1)|x))
Want more tricks? I highly recommend Henry Warren's _Hacker's Delight_:
http://www.hackersdelight.org
See also HAKMEM- MIT AI Lab Memo No. 239:
http://www.inwap.com/pdp10/hbaker/hakmem/hakmem.html
(It seems that the people at the AI lab were interested in just about
anything except AI :-)
Also the unpublished (but downloadable) Volume 4A of Knuth's _The Art of
Computer Programming_:
http://www-cs-faculty.stanford.edu/~knuth/taocp.html
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 118512The puzzling thing is that I'm not using DDR. The datasheet says "Some adjacent I/O blocks (IOBs) share common routing connecting the ICLK1, ICLK2, OTCLK1, and OTCLK2 clock inputs of both IOBs." It doesn't say which is connected to which. So even though i'm not using DDR, if ICLK1 of IOB1 is connected to ICLK1 of IOB2 and similarly for ICLK2 then there's no problem as long as ICLK1 and ICLK2 of each can function independently and OTCLK are not used at all. It's puzzling too because as I mentioned, If I remove the constraint and look at the result, the relocated IOB has no ICLK inputs used, only a buffer and then goes to two independent FFs placed somewhere else. So why can't it do that with the constraint in place? I'll try the LOC suggestion. Thanks for the explanation and suggestions. /MHS On Apr 28, 7:59 am, Gabor <g...@alacron.com> wrote: > On Apr 27, 5:49 pm, "M. Hamed" <mhs...@gmail.com> wrote: > > > > > I have two pin one is IN and the other is INOUT and they each one goes > > to the D input of two FFs clocked by two different clocks Clk1, Clk2. > > When I start the PAR process, Xilinx tool complains with the following > > error: > > > ERROR:Place:17 - The placement constraints of the IOBs sck and sdi > > makes this design unroutable due to a physical routing limitation. > > This device has a shared routing resource connecting the ICLK and > > OTCLK pins on pairs of IOBs. This restriction means that these pairs > > of pins must be driven by the same signal or one of the signals will > > be unroutable. Before continuing please remove the placement > > constraints or move one of these IOBs to a new location. > > > The strange thing is that after looking at the design in the FPGA > > editor, IOBs OTCLK are not used at all in the mentioned IOBs and for > > one of the pins, the tool is using the internal FFs in the IOB while > > in the other it's using only an input buffer and that feeds a FF in > > another slice. > > > Ofcourse removing the pin placement constraint fixes the problem but > > that is something that cannot be done for the time being. > > > I wonder if somebody can help me figure out what's going on. > > > I'm using ISE 9.1.03i with Spartan 3 > > > Thank you. > > You can't change the architecture of the chip. I ran into this same > problem in Virtex 2. Each IOB seems to have two clock inputs that > go to the two clocks of the DDR input and output flip-flops, and > even if you use the same clock for both (rising edge and falling > edge of the same wire) both routing resources are used (wires > from the global routing to the IOB. You have to dig a bit deep in > the datasheet to find it, but pairs of IOB's (the same pairs labeled > as "N" and "P" halves of a differential pair) share only two wires > to bring in these two clocks. If both IOB's are using only single > data rate flip-flops, the two wires allow them to be pretty much > independent of eachother. However when at least one has > DDR flip-flops, the two IOB's need to share clock routing. Thus > in a DDR SDRAM design for example you can't place a DQ > pin and a DQS pin in two halves of a differential pair. > > The synthesis tool has apparently worked around this issue > in your case by using fabric flip-flops for one of the two IOB's. > If you can't change the pin location in your current design, > the best you can do is to LOC the fabric slice where these > flip-flops will end up. In the package pin listings from Xilinx > there is a column showing the location of the nearest (from > a routing perspective) slice to each IOB. > > HTH, > Gabor > > PS read the section in the datasheet (ds099) titled > "Double-Data-Rate Transmission" in the IOBs functional > description. This is p. 13 in my copy which may > not be the latest version. The paragraph starting > "Some adjacent I/O blocks . . ." describes this.Article: 118513
What you are trying to do is meaningless. There is no proportionality between FPGA chip size and ASIC chip size. Some parts of an FPGA are as area-efficient as an ASIC, others consume much more area. Your starting point must be the consumed logic resources. Then forget about the FPGA area, if you want to guess at the ASIC chip area. Peter Alfke On Apr 25, 3:22 am, Pasacco <pasa...@gmail.com> wrote: > Dear > > I am looking at data book of Xilinx Virtex-II Pro > > to find ACTUAL CHIP SIZE. > > So far, I could not find yet -: > > (as an example, 900 um X 1.5 cm) > > I need a DIE (that we see in FPGA editor) size for V2P30-ff896 and > V2Pro100-ff1704. > > Can anyone help me, where I can find? Should I ask Xilinx?Article: 118514
On Apr 28, 4:24 am, eapen.abra...@gmail.com wrote: > Hi, > > Has anyone tried bridging the TS201 TigerSHARC with the PLX 9656 > device? I'm trying to implement this in a current project and need > details. The bridging is done via an Altera FPGA which also has to > have custom logic for other functions such as Ethernet, sFPDP,etc. > > I know that the TS201 core runs at 600 MHz and the I/O bus at around > 83.5 MHz. But at what speed does the PLX 9656 local bus run? Can the > TS201 be connected directly to the PLX chip? Are there anyother > alternatives to the PLX chip? The PLX9656 has four different local bus modes, but in all cases the bus is 32-bits wide at 66 MHz max. You should have no problems meeting the timing with a (recent vintage) FPGA. You won't be able to directly connect the TigerSHARC and the PLX9656 unless you get lucky and the bus on the TS201 matches one of those on the PLX9656 and can be run at 66 MHz or slower.Article: 118515
Gabor <gabor@alacron.com> wrote: >On Apr 27, 5:49 pm, "M. Hamed" <mhs...@gmail.com> wrote: >> I have two pin one is IN and the other is INOUT and they each one goes >> to the D input of two FFs clocked by two different clocks Clk1, Clk2. >> When I start the PAR process, Xilinx tool complains with the following >> error: >> >> ERROR:Place:17 - The placement constraints of the IOBs sck and sdi >> makes this design unroutable due to a physical routing limitation. >> This device has a shared routing resource connecting the ICLK and >> OTCLK pins on pairs of IOBs. This restriction means that these pairs >> of pins must be driven by the same signal or one of the signals will >> be unroutable. Before continuing please remove the placement >> constraints or move one of these IOBs to a new location. >> >> The strange thing is that after looking at the design in the FPGA >> editor, IOBs OTCLK are not used at all in the mentioned IOBs and for >> one of the pins, the tool is using the internal FFs in the IOB while >> in the other it's using only an input buffer and that feeds a FF in >> another slice. >> >> Ofcourse removing the pin placement constraint fixes the problem but >> that is something that cannot be done for the time being. >> >> I wonder if somebody can help me figure out what's going on. >> >> I'm using ISE 9.1.03i with Spartan 3 >> >> Thank you. > > >You can't change the architecture of the chip. I ran into this same >problem in Virtex 2. Each IOB seems to have two clock inputs that Afaik each IOB pair in a Spartan 3 has one clock input and a clock enable (or something like that). Bottom line is, you can use one clock in an IOB pair. >go to the two clocks of the DDR input and output flip-flops, and >even if you use the same clock for both (rising edge and falling >edge of the same wire) both routing resources are used (wires >from the global routing to the IOB. You have to dig a bit deep in >the datasheet to find it, but pairs of IOB's (the same pairs labeled >as "N" and "P" halves of a differential pair) share only two wires >to bring in these two clocks. If both IOB's are using only single This is definitely not mentioned in the Spartan 3 datasheet. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 118516
On Apr 28, 4:51 pm, n...@puntnl.niks (Nico Coesel) wrote: > Gabor <g...@alacron.com> wrote: > >On Apr 27, 5:49 pm, "M. Hamed" <mhs...@gmail.com> wrote: > >> I have two pin one is IN and the other is INOUT and they each one goes > >> to the D input of two FFs clocked by two different clocks Clk1, Clk2. > >> When I start the PAR process, Xilinx tool complains with the following > >> error: > > >> ERROR:Place:17 - The placement constraints of the IOBs sck and sdi > >> makes this design unroutable due to a physical routing limitation. > >> This device has a shared routing resource connecting the ICLK and > >> OTCLK pins on pairs of IOBs. This restriction means that these pairs > >> of pins must be driven by the same signal or one of the signals will > >> be unroutable. Before continuing please remove the placement > >> constraints or move one of these IOBs to a new location. > > >> The strange thing is that after looking at the design in the FPGA > >> editor, IOBs OTCLK are not used at all in the mentioned IOBs and for > >> one of the pins, the tool is using the internal FFs in the IOB while > >> in the other it's using only an input buffer and that feeds a FF in > >> another slice. > > >> Ofcourse removing the pin placement constraint fixes the problem but > >> that is something that cannot be done for the time being. > > >> I wonder if somebody can help me figure out what's going on. > > >> I'm using ISE 9.1.03i with Spartan 3 > > >> Thank you. > > >You can't change the architecture of the chip. I ran into this same > >problem in Virtex 2. Each IOB seems to have two clock inputs that > > Afaik each IOB pair in a Spartan 3 has one clock input and a clock > enable (or something like that). Bottom line is, you can use one clock > in an IOB pair. > > >go to the two clocks of the DDR input and output flip-flops, and > >even if you use the same clock for both (rising edge and falling > >edge of the same wire) both routing resources are used (wires > >from the global routing to the IOB. You have to dig a bit deep in > >the datasheet to find it, but pairs of IOB's (the same pairs labeled > >as "N" and "P" halves of a differential pair) share only two wires > >to bring in these two clocks. If both IOB's are using only single > > This is definitely not mentioned in the Spartan 3 datasheet. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U opwww.adresboekje.nl from ds099.pdf: Some adjacent I/O blocks (IOBs) share common routing connecting the ICLK1, ICLK2, OTCLK1, and OTCLK2 clock inputs of both IOBs. These IOB pairs are identified by their differential pair names IO_LxxN_# and IO_LxxP_#, where "xx" is an I/O pair number and '#' is an I/O bank number. Two adjacent IOBs containing DDR registers must share common clock inputs, otherwise one or more of the clock signals will be unroutable.Article: 118517
Markus,
> - OpenSUSE 10.2 also no longer uses the "hotplug" system to start custom
> scripts when some device is plugged in, therefore the patch at
>
> http://www.altera.com/support/software/drivers/dri-usb_b-lnx.html
>
> is no longer applicable. A workaround is to do the necessary
> "chmod 666 /proc/bus/usb/.../..." yourself each time after plugging
> in the cable. (TODO: find out how to configure udevd to do the same)
I'm running Gentoo Linux and was having the same problem. Took me the better
part of the morning a few weeks ago to get eveything working well, but I
solved this one. Here's how:
1 - become root
2 - Go to /etc/udev/rules.d
3 - create a file named 32-altera.rules in there containing
=== Cut here ====
# udev rules file for Altera USB programming devices (udev >= 0.98)
#
ACTION!="add", GOTO="altera_rules_end"
SUBSYSTEM!="usb_endpoint", GOTO="altera_rules_end"
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", MODE="0666"
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6002", MODE="0666"
ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6003", MODE="0666"
LABEL="altera_rules_end"
=== Cut here ====
4 - either restart udevd, or simply reboot
After that, an USB blastershould have the proper permissions once plugged
in.
Best regards,
Ben
Article: 118518Pasacco wrote: > Hello > > For research work, > > my goal is to estimate the ASIC-equivalent AREA in terms of [um^2] > > of my design implemented in Virtex-II Pro. For what final purpose ? - there will be considerable elasticity in the answer, and it has little practical relevance, as you do not buy either device by the Acre. Still, you can get ballparks without too much effort : Find the smallest package the largest FPGA in your series is offered in, and the die area must be less than that :) [ but probably not a lot less ] Or, get your hands on a dead device, and open it up. Die area is easy to see. If you want a more useful ASIC metric, take a known Industry IP block and the usage in that same FPGA, and then look at the cost of that as a Std high volume chip. -jgArticle: 118519
I've read answer record 19146 about using a series resistor for 5V tolerance on Spartan 3 inputs. If the signal source is a 74LS TTL signal (e.g., 74LS14), what is the maximum Voh I can expect (over temperature, etc.)? It's not in the specs, but I know it's not 5V. Is it above 3.3V? I'll probably just assume 5V and use a 330 ohm resistor pack, but I'd like to know the real-world limit. Thanks, EricArticle: 118520
Greetings all, Has anyone connected and used a CMUcam2 to a Digilent XUP-V2Pro FPGA board? If so, how did you do it? That is what module or connector did you use? I am trying to use the Uart lite IP through the low-speed expantion headers? Let me know of any questions or thoughts you may have. Thank you, Rob HarrellArticle: 118521
Eric Smith wrote: > I've read answer record 19146 about using a series resistor for > 5V tolerance on Spartan 3 inputs. > > If the signal source is a 74LS TTL signal (e.g., 74LS14), what > is the maximum Voh I can expect (over temperature, etc.)? It's not > in the specs, but I know it's not 5V. Is it above 3.3V? > > I'll probably just assume 5V and use a 330 ohm resistor pack, but I'd > like to know the real-world limit. Can you guarantee it is always going to be a 74LS14 ? That's one important factor in skipping the limiter, and not always under your control. Also, what is the 5V/3.3V supply tolerances - if you know that then you should be able to do a LS load line calc, to see the clamp currents. - but the answer only applies to LS14 devices... If someone uses a HC/VHC/AHC/AC device, all that flies out the window :) -jgArticle: 118522
I remember well that all real TTL LS devices have an effective two- diode drop on the output. But you can easily measure that yourself. Then the question is whether 5 V minus 1.4 V is higher than your 3.3 V, and really higher than your 3.3 V plus a diode drop. You can easily try it out, and measure the current flowing into the FPGAinput when the LS output is High. Probably is it les than a few microamps. But then the question is about tolerances: can your 5V bw high while your 3.3 V is low, and what about the start-up condition? The resistor pck avoids all these headaches. Peter Alfke On Apr 28, 4:42 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Eric Smith wrote: > > I've read answer record 19146 about using a series resistor for > > 5V tolerance on Spartan 3 inputs. > > > If the signal source is a 74LS TTL signal (e.g., 74LS14), what > > is the maximum Voh I can expect (over temperature, etc.)? It's not > > in the specs, but I know it's not 5V. Is it above 3.3V? > > > I'll probably just assume 5V and use a 330 ohm resistor pack, but I'd > > like to know the real-world limit. > > Can you guarantee it is always going to be a 74LS14 ? > That's one important factor in skipping the limiter, and > not always under your control. > > Also, what is the 5V/3.3V supply tolerances - if you know that > then you should be able to do a LS load line calc, to see > the clamp currents. > - but the answer only applies to LS14 devices... > If someone uses a HC/VHC/AHC/AC device, all that flies out > the window :) > > -jgArticle: 118523
I was wondering if anyone had considered the possibility that the new OIF SPI-S using CEI 11G links may be compatible with and thus capable of enhancing Xilinx's current Aurora mesh-based architecture using multiple aggregate lanes, or would this simply replace one standard with another? Thank you. <http://www.oiforum.com/public/documents/Introducing_SPI-S_WP_FINAL.pdf> fg--->Article: 118524
On Apr 29, 1:50 am, Gabor <g...@alacron.com> wrote: > On Apr 28, 4:24 am, eapen.abra...@gmail.com wrote: > > > Hi, > > > Has anyone tried bridging the TS201 TigerSHARC with the PLX 9656 > > device? I'm trying to implement this in a current project and need > > details. The bridging is done via an Altera FPGA which also has to > > have custom logic for other functions such as Ethernet, sFPDP,etc. > > > I know that the TS201 core runs at 600 MHz and the I/O bus at around > > 83.5 MHz. But at what speed does the PLX 9656 local bus run? Can the > > TS201 be connected directly to the PLX chip? Are there anyother > > alternatives to the PLX chip? > > The PLX9656 has four different local bus modes, but in all > cases the bus is 32-bits wide at 66 MHz max. You should > have no problems meeting the timing with a (recent vintage) > FPGA. You won't be able to directly connect the TigerSHARC > and the PLX9656 unless you get lucky and the bus on the > TS201 matches one of those on the PLX9656 and can > be run at 66 MHz or slower. Hi, Thanks for the info. I know that the PLX operates at 66MHz MAX and the TS201 at 83MHz (I/O). I need to use some asynchronous glue logic to interface both like an async fifo. The other doubt i had in mind was with regards to the control lines of the PLX and TS201. The TS201 has what is called memory banks that are used for memory, I/O accesses. Have to check up the TS201 read/write cycles and also with the PLX.
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