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
> And, yes, it was painful to trip on V4 FX, but we still beat them with a > gigabit transceiver for 90nm....just not by the six months we had > intended to originally. Perhaps *a* gigabit... but certainly not 6, nor a robust 3 :-) Sorry, couldn't resist. - PaulArticle: 102601
>> > That's not the only issue. The main problem is that the Jungo driver is >> > a security hole by design: it gives applications access to PCI cards >> > from user space without any security check, making it possible for any >> > user to read from and write to any memory location. The people who >> > designed such a piece of crap should be banned from using computers for >> > the rest of their life. >> >> Can you please cite a reference that documents this issue in detail? And >> as I originally requested is there any known exploit that takes advantage >> of this, again I need a cite. I looked and I can't find anything other >> than comments that are 4+ years old at this time. > > Sure. Give me access to a PCI bus master (say the IDE) device, and I > can splat whatever data it contains (say a binary I compiled) into > whatever portion of memory (say kernel address space) I want it to go. That's exactly the point. WinDriver gives access to PCI devices from userspace. Any PCI bus master can then be used to modify system memory. There are many more ways to gain root privileges once you can access device and/or system memory. Loïc Duflot published a very interesting paper describing how to gain root access (and doing much more) using the AGP aperture and SMM: http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/sstic2006-duflot-papier.pdf > Oh, you need a "cite"... Well, if you're in the "know" and understand > the implications, the following should make you cringe: > > http://www.cansecwest.com/speakers.html#duflot > >> If there is truly an issue here I will look into it further as my group >> is one of licensees of Jungo drivers, but so far all I've seen is FUD for >> "closed source" code. How do you expect people to trust a closed-source driver which main purpose is to enable userspace applications to access devices directly ? Especially when there are safe open source multiplatform alternatives (libusb). > If I get userland access to poke into I/O or device memory, I will take > over your machine. Laurent PinchartArticle: 102602
As long as you have the right timing constraints in Quartus II, swap around the pins and give it a whirl. 33 Mhz PCI is pretty easy to meet in any Cyclone II device. Regards, Paul Leventis Altera Corp.Article: 102603
fpga_toys@yahoo.com wrote: > Ed McGettigan wrote: > > Ed ... you missed the point. JTAG is "supposed" to be an open standard > interface, > usable for a large number of in system interfaces, and Xilinx is > turnning it into another > proprietay closed interface with VERY limited static sequences exported > to the user. > > Consider that JTAG is the ideal port to introduce a source level > debbugger interface > into HLL reconfigurable computing netlists, which would require an open > interface to > plug a gdb/ddd backend onto. Having to create one JTAG chain for Xilinx > tools, and > one each for other vendors tools, and a separate one for your own > debbuging tools > is a total crock, and violation of what is "supposed" to be an open > interface standard > test port. > Xilinx has done nothing to deviate from the IEEE JTAG standards as defined in the IEEE 1149.1 and IEEE 1532 specifications. All Xilinx devices have corresponding JTAG BSDL files for both 1149.1 and 1532 publicly released both on our web site and in every software release. These files fully conform to the appropriate IEEE specification. These files and the IEEE standards are all that is needed for anyone to create software and hardware to communicate with Xilinx devices through the JTAG interface along with any other devices in the same chain. If you do not like the software and hardware that we provide for this function and if no one else does either then you should go ahead and create what you want instead. On the hardware comms front, Macraigor (http://www.macraigor.com) sells various JTAG communication hardware and has (had??) GDB support so you might want to start there first. I'm sure that there are other providers out there as well that you can find if not then go ahead and create your own JTAG communication hardware. One thing is certain, if it meets the IEEE JTAG electrical specs and wiggles the bits as defined in the IEEE standards it will work with our devices. Ed McGettigan -- Xilinx Inc.Article: 102604
Hi: One more point. You can now configure the Spartan-3 FPGAs with a low cost Configurator from Atmel. Atmel offers 8-pin LAP packages for AT17Fxxx in densities upto 16 Mbit; AT17Nxxx family from Atmel is a low cost Conf. family; Check out Digikey for low quantities YArticle: 102605
MaxII is not really a follow-up of MAX7000 or the MAX3000A family. One should call this a Mini-Cyclone FPGA. The equivalent of Coolrunner-II is Atmel's ATF15xxBE family. they have the best low volume pricing; Checkout Digikey YArticle: 102606
Ed McGettigan wrote: and again you completely missed the point. Does Xilinx provide an open specification so that 3rd party software can use your expensive JTAG interfaces? Does Xilinx provide and open specification so that 3rd party JTAG hardware interfaces are usable with expensive Xilinx software? The complaint as I listen to this thread is that Xilinx does neither, instead offering a closed development environment which allows neither 3rd party hardware or software interfaces, that also creates a trojan root kit interface ... is that not the issue?Article: 102607
Ed McGettigan wrote: > If you do not like the software and hardware that we provide for this > function and if no one else does either then you should go ahead and > create what you want instead. Is that permission to replace the Xilinx bit stream tools by reverse engineering and providing open source replacements? The bitch ... is that Xilinx requires users to use the Xilinx usb adapter to program, then unplug the Xilinx usb JTAG interface, from a possibly live board, then plug another 3rd party (or home grown) JTAG into the board to do testing or configuration of non-xilinx device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG interface when it's necessary to reprogram a Xilinx part on the JTAG chain. First, this is POOR practice on a live board, and labor intensive in any case. Second it's completely unnecessary, except for Xilinx's refusal to provide open development tools interfaces for the JTAG environment so that either a 3rd party usb adapter can be used, or 3rd party software with your adapter.Article: 102608
One more thing. If you have 7 or less applications that you want to load
from System ACE CF there is an even simpler approach.
In that case the software applications are embedded into software only
ACE files and stored in the directory structure for System ACE CF. For
example, the bootloader is at configuration address 0, application 1 at
address 1, etc. The bootloader consists of only a few lines of code that
selects the desired configuration and kicks off a System ACE CF
configuration cycle for that application.
For more information check out the reference design for the ML403 board
at
http://www.xilinx.com/products/boards/ml403/files/ml403_emb_ref_ppc_81.zip
(see source code in sw/standalone/bootload/src)
- Peter
Peter Ryser wrote:
> Here is some information on how to get this done. This is tested on a
> ML403 board. You might need to make changes for your environment but the
> principle is the same.
>
> 1. Use Base System Builder and build a design with UartLite, System ACE
> CF, and DDR memory. Include the BRAM, we'll use it initially.
> 2. Build the hardware.
> 3. Add a software project
> - bootloader: the bootloader program that will run out of cache
> 4. Implement the bootloader (runs out of BRAM by default). Test it on
> the board.
> 5. Now let's move the bootloader application into caches. For that we
> create a new linker script with three memory regions:
> MEMORY
> {
> icache : ORIGIN = 0x70000000, LENGTH = 16k - 4
> boot : ORIGIN = 0x70003ffc, LENGTH = 4
> dcache : ORIGIN = 0x78000000, LENGTH = 16k
> }
> Separate all the sections into those regions. At this time you have a
> real Harvard architecture, i.e. you need to be careful about moving
> instructions into the icache and data into the dcache. Rebuild the
> bootloader application.
> 6. Set the XMD Debug Options. In the Advanced Options tab set the icache
> to 0x70000000 and the dcache to 0x78000000. Save.
> 7. Download the bootloader application and run. It now runs out of caches.
>
>
> The project is attached.
>
> - Peter
>
>
>
>
> Jon Beniston wrote:
>
>> Peter,
>>
>>
>>> assuming that you are using System ACE CF to configure your Virtex-4 FX
>>
>>
>>
>> Yep.
>>
>>
>>> can load the boot code directly into the processor caches
>>
>>
>>
>> Thanks sounds very interesting. Any pointers or app notes on how to do
>> this? (Sorry if I'm overlooking the obvious)
>>
>> Cheers,
>> Jon
>>
Article: 102609Greetings, I want to know the input setup/hold and clock-to-out times for LVCMOS18 fast 16mA for an LX40-10 part, and I'm not 100% sure that my interpretation of the data sheet quantities are correct. With V2/V2Pro, the information in the data sheets seemed more straight forward. Here's how I think the input setup/hold and clock-to-out times are calculated. I've used the latest V4 data sheet from the web (Virtex-4 Data Sheet: DC and Switching Characteristics DS302 (v1.12) March 22, 2006) - ----------------------------------------------------- Input setup/hold time: Page 45 says that for an LX40-10 part the system synchronous (no input delay) setup/hold time, for LVCMOS25, is 1.50ns/-0.46ns. Now, there needs to be an adjustment of the setup/hold time for LVCMOS18. Per page 22, Tiopi is 0.88ns for LVCMOS25. Per page 23, Tiopi is 1.25ns for LVCMOS18. I would assume that one would now subtract Tiopi for LVCMOS25 from that of LVCMOS18 and then add the difference to the system synchronous LVCMOS25 setup time, and subtract the difference from the hold time, in order to calculate the system synchronous LVCMOS18 setup/hold time: LVCMOS18 setup time = 1.50ns + (1.25ns - 0.88ns) = 1.87ns LVCMOS18 hold time = -0.46ns - (1.25ns - 0.88ns) = -0.83ns Is this correct? ----------------------------------------------------- Clock-to-out time: Page 43 says that for an LX40-10 part the system synchronous global clock input to output delay, for LVCMOS25 fast 12mA, is 3.32ns. Now, there needs to be an adjustment of the clock-to-out time for LVCMOS18 (fast 16mA). Per page 22, Tioop is 2.43ns for LVCMOS25 (fast 12mA). Per page 23, Tioop is 2.27ns for LVCMOS18.(fast 16mA) I would assume that one would now subtract Tioop for LVCMOS18 (fast 16mA) from that of LVCMOS25 (fast 12mA) and then subract the difference from the system synchronous LVCMOS25 (fast 12mA) clock-to-out time. LVCMOS18 (fast 16mA) clock-to-out time = 3.32ns - (2.43ns - 2.27ns) = 3.16ns Is this correct? ----------------------------------------------------- Thanks, BobArticle: 102610
binaryboy wrote:
> is it easy to reverse engineer ASIC/FPGA ?
> do u have any reference for this ?
You might want to talk with Ed McCauley:
http://www.bltinc.com/Services.Xilinx-Reverse-Engineering.htm
Article: 102611Following up on an older thread: http://www.fpga-faq.org/archives/97450.html#97451 http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/84104bcc0cbd0ff1 Thanks to everyone who posted or emailed with suggestions, or just to say they found those notes helpful. I've updated that earlier file with PRBS eye diagrams, alternate termination schemes, comparison with IBIS models, and notes on probes and probe loading: http://members.aol.com/fpgastuff/lvds_current.pdf http://members.aol.com/fpgastuff/lvds_current.zip BrianArticle: 102612
Peter Alfke wrote: > There is a guaranteed glitch-free clock multiplexer design in "six easy > pieces", #6 > Find it under TechXclusives on the Xilinx website, or click on: >http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=-1211408&iLanguageID=1&multPartNum=1 > &sTechX_ID=pa_six_easy&languageID=1 > > Sorry for the ridiculously long URL. > Peter Alfke, Xilinx It's not a very useful UR - generates following from Mozilla: http://www.xilinx.com/tech_difficulties.htm Sorry... Technical difficulties with the Xilinx.com web site have been solved. If you are continuing to have difficulty accessing Xilinx.com, you may need to exit your browser software and restart it. Please accept our apologies for any difficulties you have experienced. obviously not solved :(Article: 102613
fpga_toys@yahoo.com wrote: > Peter Alfke wrote: > >>There is a guaranteed glitch-free clock multiplexer design in "six easy >>pieces", #6 >>Find it under TechXclusives on the Xilinx website, or click on: >>http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=-1211408&iLanguageID=1&multPartNum=1 >>&sTechX_ID=pa_six_easy&languageID=1 >> >>Sorry for the ridiculously long URL. >>Peter Alfke, Xilinx > > > It's not a very useful UR - generates following from Mozilla: > > http://www.xilinx.com/tech_difficulties.htm > Sorry... > Technical difficulties with the Xilinx.com web site have been solved. > If you are continuing to have difficulty accessing Xilinx.com, you may > need to exit your browser software and restart it. Please accept our > apologies for any difficulties you have experienced. > > obviously not solved :( Seems to have moved to here ? http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1 -jgArticle: 102614
hm to my understanding the V4 MGT are stripped down from original spec (10G) to meat the serdes in Stratix-IIGX ? So where do the V4 serdes beat SII-GX ? Perhaps they do, but for me it's not so obvious (not since the virtex 10G rocketio is "taken out" from V2Pro-X and V4). Paul, I assume Cyclone-III, Stratix-III, MAX3 products will come H1 2007, (based on Altera claim that 65nm Altera products are announed late 2006) - I wonder if Altera will get the 65nm products (some) out this year? If we can expect the announcement, then I would assume Altera would claim their 65nm being shipped at the time of the press release (late 2006?)Article: 102615
fpga_toys@yahoo.com wrote: > Ed McGettigan wrote: > > and again you completely missed the point. > > Does Xilinx provide an open specification so that 3rd party software > can use your expensive JTAG interfaces? A IEEE 1149.1 and/or IEEE 1532 JTAG interface is available in all of our modern FPGAs (not available in the XC2000, XC3000 and part of XC4000 families) for configuration, boundary scan and internal user extensions. It is simple and easy to use with 4 pins TDI, TDO, TMS and TCK and conforms to the public IEEE interface standards. We have chosen to not implement the optional TRST pin. We have also chosen to implement allowed optional extensions to permit internal USER scan chains. The JTAG interface is not expensive to use. All needed documentation on how to perform traditional JTAG boundary scan can be found in the IEEE specification and the appropriate BSDL file. All needed documentation on how to configure a device from a binary bitstream can be found in the IEEE specification and the appropriate BSDL file and datasheet. All needed documentation on how to create and use the internal USER scan chains can be found in the IEEE specification and the appropriate BSDL file and datasheet. More information is also provided in Xilinx Application Note XAPP058 http://www.xilinx.com/bvdocs/appnotes/xapp058.pdf which documents various consideration and even includes a C routing for JTAG programming from a microprocessor. It is not as hard as rocket science, but it is harder than falling off a log. > Does Xilinx provide and open specification so that 3rd party JTAG > hardware interfaces are usable with expensive Xilinx software? Xilinx software is designed to work with Xilinx communication cables and some selected 3rd party equipment. Our software is tightly coupled to the communication hardware and we do not provide general access to the driver/software APIs. Ed McGettigan -- Xilinx Inc.Article: 102616
fpga_toys@yahoo.com wrote: > Ed McGettigan wrote: >> If you do not like the software and hardware that we provide for this >> function and if no one else does either then you should go ahead and >> create what you want instead. > > Is that permission to replace the Xilinx bit stream tools by reverse > engineering and providing open source replacements? Since the function that I was discussing was configuration through iMPACT and a Xilinx USB JTAG cable and you have twisted this into something completely different then of course your answer is no. > > The bitch ... is that Xilinx requires users to use the Xilinx usb > adapter to program, then unplug the Xilinx usb JTAG interface, from a > possibly live board, then plug another 3rd party (or home grown) JTAG > into the board to do testing or configuration of non-xilinx > device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG > interface when it's necessary to reprogram a Xilinx part on the JTAG > chain. There is no truth to this assertion. Our devices can be configured by many, many, many different means. Hundreds, if not thousands, of pages are available on www.xilinx.com describing how to take a generated bitstream and use it configure a device. Ed McGettigan -- Xilinx Inc.Article: 102617
Ed McGettigan wrote: > fpga_toys@yahoo.com wrote: > > Ed McGettigan wrote: > > > > and again you completely missed the point. > > > > Does Xilinx provide an open specification so that 3rd party software > > can use your expensive JTAG interfaces? Ok, interface is too general a term, as is cable, of which an active usb device is more than a cable, and hence refered to as an interface. so, Does Xilinx provide an open specification so that 3rd party software can use your expensive "usb" JTAG interface devices/cables/converters?Article: 102618
Hi, I am tring to install Altera Quartus II v6.0 under Debian 3.1. During the install process, the install script ask me to insert the CD: Quartus II Device Information for UNIX & Linux CD, but I searched within the www.alter.com, I cannot find it. Does anyone here has got the CD? thanks.Article: 102619
Kees van Reeuwijk wrote: > Except that there is no way to compile standard software to an FPGA, or > even to compile freshly created software in anything near a normal > programming langage. I hope you don't expect that the bulk of > C/C++/Java/C# programmers will learn VHDL or Verilog. No need to. Software guys step up to architecture issues all the time, although major programming changes take training time, just as in hardware. The biggest hit is that the trendy object oriented designs are memory centric, and will always be to some extent. But even there, since objects instantiate from a pool by the creator for that class, and interfaces can be message oriented, it's very possible to design around classes that live on top of block rams and LUT rams, and use fabric bulk memories as a backing store. Even with tradition programming styles, most are easy to fit into an FPGA, they just loose some of their performance when they single thread around a single memory object. Most current generation programmers are taught threading and messaging using distributed clusters, and that programming model scales into large FPGA easily. With the upper end V5 LX330 devices being really LUT rich, computing on these things is easy. Now if they just cost the same as a COTS processor for equiv die size, it would be a huge win.Article: 102620
Austin Lesea wrote: > Intel proposes a future with more than 200 x86 cores on one die, with a > "communications fabric" and many memories. All on one die. Small > software problem to be solved by the need to have it solved.... Do you have a ref on that (an url perhaps?) I'm really interested... I tried Google but I'm obviously not feeding it the right keywords. Thanks, -- PeterArticle: 102621
Greg Neff wrote: > My first thought was a datasheet error, and there it is. Hooray, it's not my fault :) Mind you, I evidently should have checked for errata. Thanks, Greg. -- PeterArticle: 102622
On 17 May 2006 12:35:23 -0700, Eric Smith <eric@brouhaha.com> wrote: >ghelbig@lycos.com writes: >> And let's not forget that Xilinx owns the USB Vendor ID for the device, >> so one can't re-use it without their permission. > >Why? Xilinx doesn't have a copyright, trademark, patent, or trade >secret on their USB vendor ID. I don't recall that I've ever signed a >contract with Xilinx (or anyone else) stating that I would not use the >Xilinx USB vendor ID for something else (e.g., a Xilinx-compatible >cable). > >Anyhow, you could always ship a product with some other USB vendor ID, >and supply a tool that allowed the user to change the vendor ID to >any numeric value of his or her choice. AFAIK The only thing you can't do with a borrowed/made-up VID/PID is use the USB logo.Article: 102623
Atmel_PLDs_Rock <ydhami@gmail.com> wrote: > Hi: > One more point. You can now configure the Spartan-3 FPGAs with > a low cost Configurator from Atmel. Atmel offers 8-pin LAP packages > for AT17Fxxx in densities upto 16 Mbit; > AT17Nxxx family from Atmel is a low cost Conf. family; > Check out Digikey for low quantities Out of stock... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 102624
>What's the speed ..? up to 100 Mhz. >Voltage levels ..? analog input signal is between -1V and 1V >Cost ..? cost is not a problem >Complexity ..? What do you want to say with the term "complexity" ? I need to convert it to an 8 bits format. Thanks for your replies
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