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
On Nov 9, 2:37 pm, "Symon" <symon_bre...@hotmail.com> wrote: > > > FYI, some of Xilinx's RAMs have a similar (maybe the same?) problem.http://www.xilinx.com/support/answers/21870.htm > HTH., Syms. This is correct,and we document it also, after having detected this accidentally. If the RAM is selected, even if WE is inactive, a violation of the address set-up time CAN occasionally corrupt the RAM=ROM content. This may sound strange. How can anything write a data corruption when WE is inactive? If address lines change at a certain place inside the specified set-up time window, then two different address decoders can be activated simultaneously, and interconnect different data locations through their sneak path. Ugly! It's not very likely, but we have measured it. It is real. Moral: Never violate the address timing with repect to the set-up time before the active clock edge. If you have to violate it, make sure that the Memory Enable signal is inactive, not only the Write Enable. Then there will be no problem whatsoever. Peter Alfke, Xilinx ApplicationsArticle: 125951
> it is SUPER SECRET :( > > thats also the reason there are no 3rd party drivers > thats the reason why it works so bad - on most cases the Cable IV > works in Cable III fallback mode because of SUPERS**** windriver stuff > that just failes The Parallel cable IV DLC7 rev4 uses Xilinx XCR3384XL (384 Macrocell CPLD, 5V tolerant I/O pins with 3.3V core supply) and 40.000MHz clock. Which software makes direct use of this cable ..?, trying to figure out a setup for testing. Such that I can trigger an operation and measure the resulting action. The P-IV advantages over a plain parallel port interface is likely only data integrity and improved speed over plain bit-banging. So it uses ECP to get fast data transfer and add some data integrity check like crc. Uses some fifo that directly feed the fpga through jtag or cclk/d0 interface. In essence: Parallel ECP -> CRC -> FIFO -> Bitbang Otoh, It seems almost simpler to put together a CPLD + PHY and some cables that will do the job without loops & hoops :), but a finished circuit has some advantages. Don't forget to bite the hand that buys from you! :-)Article: 125952
Hi, I am trying to generate system ACE file in EDK 9.1 . I am trying to combine bitstream with zImage.elf which is used to boot Monta vist linux in XUP board. I am using the following command to generate it. "xmd -tcl genace.tcl -opt genace.opt" I was able to generate it with out any error in EDK 8.1. Can Any one suggest some solution? Thank you, AjithArticle: 125953
Hi, I am ajith again. Sorry I forgot to tell you about the error message. The error that I am getting is "Unable to open ELF file, ELF file might have corrupted." ajith.Article: 125954
On Nov 9, 7:38 pm, Peter Alfke <pe...@xilinx.com> wrote: > If the RAM is selected, even if WE is inactive, a violation of the > address set-up time CAN occasionally corrupt the RAM=ROM content. > This may sound strange. > How can anything write a data corruption when WE is inactive? Yes, that's what had us all scratching our heads today! > If address lines change at a certain place inside the specified set-up > time window, then two different address decoders can be activated > simultaneously, and interconnect different data locations through > their sneak path. Ugly! > > It's not very likely, but we have measured it. It is real. Aha, now that actually makes sense. I wonder if the same mechanism is at fault for the very real behaviour I'm seeing in an Altera part when I turn the clock source on and off. I have verified that deactivating the memory's clock enable will "protect" it from clock irregularities... unfortunately, the memory is in use nearly full time. I've received a suggestion to use the PLL for the logic, and use the lock output to drive the memory enable... will have to try that next week. Clock PLL by itself reduced the risk of corruption substantially, but not to zero.Article: 125955
On Nov 9, 7:46 pm, kgll...@yahoo.com wrote: > The P-IV advantages over a plain parallel port interface is likely > only data integrity and improved speed over plain bit-banging. So it > uses ECP to get fast data transfer and add some data integrity check > like crc. Uses some fifo that directly feed the fpga through jtag or > cclk/d0 interface. In essence: > Parallel ECP -> CRC -> FIFO -> Bitbang I this day and age you might as well use USB, getting you compatability with your travel laptop, etc...Article: 125956
On Nov 8, 10:14 am, Kryvor <kris.vorw...@gmail.com> wrote: > You might find that Actel suits your needs ... > > http://www.actel.com/documents/selguide.pdf > > (It looks as though Actel carries some smaller ProASICPlus parts in a > TQFP 100 package. Those parts have 2 PLLs and are Flash-based > [reprogrammable, immune to SEUs, etc.].) Yes, however there's a big differnece between developing for these vs. Altera or Xilinx SRAM parts: the toolchain is less integrated and thus much slower, and the programmer is outrageously slow and pricey for what you get. If you are used to fully integrated toolflow, and to doing fast test downloads during development, this can be quite aggravating. It also seems that you can't get pullups on inputs, and instead of merely being cautioned against using non-clock inputs as clocks, you literally can't do it - meaning board designs with stupid mistakes that might be programmed away with other devices are more likely to require modifications with these. On the other hand, if you prefer to do everything in simulation and not make incremental trials in hardware, and you value synopsis over X or A's tools enough to habitually use it anyway, then maybe these parts are just your thing.Article: 125957
When looking at this schematic: http://www.xilinx.com/support/programr/jtag_cable.pdf And comparing with the pcb layout of Insight jtag IJC-02 parallel port dongle. They seem to be the same thing. Is that so .. ? Any catches with it?, I saw some posts about removing C1 and unnecessary filtering. I assume that it's powered from the circuit to be programmed, and thus using the 74HC125D capability to withstand +5V while powering it from a lower voltage to make it's outputs compatible with the +2.5V or +3.3V circuit. (maybe next project will be Ethernet PHY+CPLD+Jtag :-)Article: 125958
On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote: > On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote: > > > > > On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote: > > > > On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote: > > > > > i want to read & write data to/from a fifo placed in fpga. MCU's > > > > external bus is connected to the chip. I am using the sync-fifo ip of > > > > Altera CycloneII. The data bus and control signal are connected to > > > > fifo directly. it's unfortune that when i read once from bus, data > > > > would be read twice from fifo because there are two clock rising edges > > > > during read signal(low active) is resetted. I think it will read more > > > > datas from fifo if the read signal is resetted long enough. > > > > Is there any good design for fifo interface connecting on the > > > > exteranl bus? > > > > Using a Synchronous FIFO implies that the read clock and the write > > > clock are in the same clock domain. Is your MCU supplying the FIFO's > > > clock or is the FPGA supplying the MCU's clock? If the clock sources > > > are different, then you either need an Asynchronous FIFO, or you need > > > to run the MCU and FPGA from the same clock. > > > HTH > > > -Dave Pollum > > > It is in different clock, i tried altera's asynchronous FIFO which > > need two extra clock for reading. > > is there any better solution? > > If your MCU is running much slower than the FPGA, you can use the > FPGA's internal clock to run the synchronous FIFO, and a little > state logic to generate the necessary (single cycle) pulses for > read and write from the MCU interface signals. unfortunately, the problem i met is on the contrary. MCU is much faster then FPGA, about 4 times.Article: 125959
cs_posting@hotmail.com writes: > I this day and age you might as well use USB, getting you > compatability with your travel laptop, etc... However, if you want to write your own code to talk to the standard firmware of the Xilinx Platform USB Cable (rather than using Impact, Chipscope, and XMD), you'll probably *still* have to reverse-engineer the CPLD bits.Article: 125960
Peter Alfke wrote: > If the RAM is selected, even if WE is inactive, a violation of the > address set-up time CAN occasionally corrupt the RAM=ROM content. Thanks for psting about the problem and the cause. Is this true of all Xilinx parts with BRAM? Is there any plan to "fix" it in future FPGAs? Can I assume that the ISE post-P&R static timing analysis will generate an error if the BRAM address setup time will not be met? I"m not sure of the limitations of the static timing analysis, but I've never seen any such error reported, so maybe my designs are OK. EricArticle: 125961
On Nov 9, 10:05 pm, Eric Smith <e...@brouhaha.com> wrote: > Peter Alfke wrote: > > If the RAM is selected, even if WE is inactive, a violation of the > > address set-up time CAN occasionally corrupt the RAM=ROM content. > > Thanks for psting about the problem and the cause. Is this true of > all Xilinx parts with BRAM? Is there any plan to "fix" it in future > FPGAs? > > Can I assume that the ISE post-P&R static timing analysis will generate > an error if the BRAM address setup time will not be met? I"m not sure > of the limitations of the static timing analysis, but I've never seen > any such error reported, so maybe my designs are OK. > > Eric The problem is somewhat exotic. Violating address timing with respect to the clock would obviously always be a disaster when WE is active (You would write data into weird uncontrolled locations). Intuitively one might think that this should not be a problem in read mode, although the data output would of course be garbage. We had one user with asynchronously free-running address sequences, but his system ignored the output most of the time. He ws very surprised when he found the data contaminated. In his case the solution was trivial: Disable the BRAM whenever possible. I do not know about atomatic warnings. A clock is also called a "trigger", and it might be wise to remember the weapons-derived origin... Peter Alfke, XilinxArticle: 125962
On Nov 9, 10:34 pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Nov 9, 10:05 pm, Eric Smith <e...@brouhaha.com> wrote: > > > Peter Alfke wrote: > > > If the RAM is selected, even if WE is inactive, a violation of the > > > address set-up time CAN occasionally corrupt the RAM=ROM content. > > > Thanks for psting about the problem and the cause. Is this true of > > all Xilinx parts with BRAM? Is there any plan to "fix" it in future > > FPGAs? > > > Can I assume that the ISE post-P&R static timing analysis will generate > > an error if the BRAM address setup time will not be met? I"m not sure > > of the limitations of the static timing analysis, but I've never seen > > any such error reported, so maybe my designs are OK. > > > Eric > The problem may have been around for many years and several device generations. It obviously was a "sleeper", since nobody detected it, or was bothered by it, in hundreds of millions of working systems. There are no plans to"fix" it, since any change would severely reduce the RAM performance, Violating set-up time requirements just falls into the "don't do that !" category. Peter Alfke > The problem is somewhat exotic. Violating address timing with respect > to the clock would obviously always be a disaster when WE is active > (You would write data into weird uncontrolled locations). > Intuitively one might think that this should not be a problem in read > mode, although the data output would of course be garbage. > We had one user with asynchronously free-running address sequences, > but his system ignored the output most of the time. He ws very > surprised when he found the data contaminated. In his case the > solution was trivial: Disable the BRAM whenever possible. > I do not know about atomatic warnings. > A clock is also called a "trigger", and it might be wise to remember > the weapons-derived origin... > Peter Alfke, XilinxArticle: 125963
On 10 Nov., 06:59, Eric Smith <e...@brouhaha.com> wrote: > cs_post...@hotmail.com writes: > > I this day and age you might as well use USB, getting you > > compatability with your travel laptop, etc... > > However, if you want to write your own code to talk to the standard > firmware of the Xilinx Platform USB Cable (rather than using Impact, > Chipscope, and XMD), you'll probably *still* have to reverse-engineer > the CPLD bits. yes if you want to talk to ANY currently supported by xilinx cable you need RE :( only cable IV and usb cable are supported since xilinx has officially dropped Cable III support AnttiArticle: 125964
Hi, On Sat, 03 Nov 2007 22:04:14 -0000, roger wrote: > I have installed the usb-driver from http://www.rmdir.de/~michael/xilinx > and I have managed to light up the green led to the usb download cable > on the spartan 3e starter kit. The green led is going black every 6-8 > second and then green again. I have not heard of this behaviour previously. For me this seems to indicate that the cable gets dis- and reconnected all the time. Do you see reoccuring dis-/reconnects in "dmesg". > I don't manage to get a connection to the board using Impact. lsusb > gives me the following: > > Bus 005 Device 012: ID 03fd:0008 Xilinx, Inc. > [...] > can't get device qualifier: Operation not permitted What are the permissions on /dev/bus/usb/005/012 (or the current location of the cable)? This error might show there is a permission problem. You did add the MODE-line to an udev rules-file? > and Impact says: > > Connecting to cable (Usb Port - USB21). > Checking cable driver. > File version of /usr/share/xusbdfwu.hex = 1025(dec), 0401. > libusb-driver.so version: 2007-10-08 15:43:55. > Cable connection failed. If you preload libusb-driver-DEBUG.so instead of libusb-driver.so you get a much more detailed output, which could tell why impact does not find the device (which according to your lsusb-output has the correct firmware loaded). Regards, MichaelArticle: 125965
On Nov 9, 12:42 pm, John LeVieux <jla...@yahoo.com> wrote: > On Nov 8, 8:41 pm, raull...@hotmail.com wrote: > > > On Nov 7, 10:02 pm, John_H <newsgr...@johnhandwork.com> wrote: > > > > raull...@hotmail.com wrote: > > > > i would like to ask how can i capture the FPGA master clock signal in > > > > the oscilloscope? Bcos in the data sheet, it indicates that the master > > > > clock is located at pin N9 which is not accessible externally. please > > > > help. thanks a million > > > > Are you *sure* this signal is not externally accessible? Typically the > > > BGA package has a matrix of pads and vias. The via for the clock signal > > > should be exposed on the back of the board, ready for a steady hand to > > > probe the clock right there "at" the package ball. > > > i am using the XEM3010 board. really have no idea how to tap the > > signal. please help.. > > Is there a schematic available in the XEM3010 documentation? If so, it > should be possible to find another pin somewhere else on the board > where the same clock signal can be probed with your oscilloscope. > > John LeVieux I use BRK3010 the BreakOut Board for XEM3010 and it maps most pins to an easy to probe test points. N9 is not mapped but I remember measuring the PLL CLKA output on the XCLK1 Test point of the BRK3010 board.Article: 125966
Readon wrote: > On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote: >> On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote: >> >> >> >>> On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote: >>>> On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote: >>>>> i want to read & write data to/from a fifo placed in fpga. MCU's >>>>> external bus is connected to the chip. I am using the sync-fifo ip of >>>>> Altera CycloneII. The data bus and control signal are connected to >>>>> fifo directly. it's unfortune that when i read once from bus, data >>>>> would be read twice from fifo because there are two clock rising edges >>>>> during read signal(low active) is resetted. I think it will read more >>>>> datas from fifo if the read signal is resetted long enough. >>>>> Is there any good design for fifo interface connecting on the >>>>> exteranl bus? >>>> Using a Synchronous FIFO implies that the read clock and the write >>>> clock are in the same clock domain. Is your MCU supplying the FIFO's >>>> clock or is the FPGA supplying the MCU's clock? If the clock sources >>>> are different, then you either need an Asynchronous FIFO, or you need >>>> to run the MCU and FPGA from the same clock. >>>> HTH >>>> -Dave Pollum >>> It is in different clock, i tried altera's asynchronous FIFO which >>> need two extra clock for reading. >>> is there any better solution? >> If your MCU is running much slower than the FPGA, you can use the >> FPGA's internal clock to run the synchronous FIFO, and a little >> state logic to generate the necessary (single cycle) pulses for >> read and write from the MCU interface signals. > > unfortunately, the problem i met is on the contrary. MCU is much > faster then FPGA, about 4 times. > - Just for info purposes what is the fpga clk rate and MCU rate? - What is the fastest clk available on pwb? - Does the MCU provide a clk at all for this interface? ie synchronous interface? Personally, I like to have an FPGA clk that is faster than any of my interfaces, or I use a clk from the fastest source on the pwb, and make my logic synchronous to that source, or I hope that if I have a high speed interface, there is an external clk that I can use, and limit the use of this clk within the fpga to just that interface.. That being said you are where you are. You might want to look at using the clk multiplier function in the Cyclone. You will be able to generate a higher clk fpga rate than you currently have, treat the read pulse asynchronously, and use the trailing edge detect I previously described. Since it is now asynchronous you will have to make the single FF, two FF and decode your edge detect off of these signals. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. Colorado Based Xilinx Consultant phone : 303.926.0068 email : jretta@rtc-inc.com web : www.rtc-inc.comArticle: 125967
On Nov 10, 12:59 am, Eric Smith <e...@brouhaha.com> wrote: > cs_post...@hotmail.com writes: > > I this day and age you might as well use USB, getting you > > compatability with your travel laptop, etc... > > However, if you want to write your own code to talk to the standard > firmware of the Xilinx Platform USB Cable (rather than using Impact, > Chipscope, and XMD), you'll probably *still* have to reverse-engineer > the CPLD bits. But why would you want to use an expensive proprietary cable? Get a cheap board with the cypress fx2 chip and implement a programmer on that. If you really want a manufacturer design for some reason, I believe the working of the altera usb blaster has been explained well enough that emulating it in an fx2 is possible. Besides, wouldn't it be fun to program a xilinx part with an (emulated) altera cable?Article: 125968
Readon wrote: > On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote: >> On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote: >>> On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote: >>>> On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote: >>>>> i want to read & write data to/from a fifo placed in fpga. MCU's >>>>> external bus is connected to the chip. I am using the sync-fifo ip of >>>>> Altera CycloneII. The data bus and control signal are connected to >>>>> fifo directly. it's unfortune that when i read once from bus, data >>>>> would be read twice from fifo because there are two clock rising edges >>>>> during read signal(low active) is resetted. I think it will read more >>>>> datas from fifo if the read signal is resetted long enough. >>>>> Is there any good design for fifo interface connecting on the >>>>> exteranl bus? >>>> Using a Synchronous FIFO implies that the read clock and the write >>>> clock are in the same clock domain. Is your MCU supplying the FIFO's >>>> clock or is the FPGA supplying the MCU's clock? If the clock sources >>>> are different, then you either need an Asynchronous FIFO, or you need >>>> to run the MCU and FPGA from the same clock. >>>> HTH >>>> -Dave Pollum >>> It is in different clock, i tried altera's asynchronous FIFO which >>> need two extra clock for reading. >>> is there any better solution? >> If your MCU is running much slower than the FPGA, you can use the >> FPGA's internal clock to run the synchronous FIFO, and a little >> state logic to generate the necessary (single cycle) pulses for >> read and write from the MCU interface signals. > unfortunately, the problem i met is on the contrary. MCU is much > faster then FPGA, about 4 times. I can get 600 Mb/s connections on a $5 FPGA. I don't know any fast MCUs though the front side bus on some embedded processors can get pretty fast. It sounds like you have an extremely simple logic problem. The read from the MCU is too wide compared to the sync FIFO's clock. Change that! If you know that you'll only have one read during a read signal from the MCU, use that information to only assert the read control to the sync FIFO once. *Do not* connect the double-wide read pulse directly to the MCU. This is very, very simple logic.Article: 125969
Hello group, I'm new to this field and currently learning how 16v8 architecture is designed. Of course, pretty confused but as my first experiement I need to implement a logical function and also design multiplier using 61v8. does anybody know where I can get some information to be able to complete this? Regards, amitArticle: 125970
On Sat, 10 Nov 2007 18:25:35 -0000, Amit <amit.kohan@gmail.com> wrote: > >Hello group, > >I'm new to this field and currently learning how 16v8 architecture is >designed. Of course, pretty confused but as my first experiement I >need to implement a logical function and also design multiplier using >61v8. > > >does anybody know where I can get some information to be able to >complete this? A GAL16V8, which I guess is what you mean, has only... - 8 bits of storage - 18 user I/O pins, of which one must be taken as a clock in most cases so your multiplier surely cannot be very big! You could make a multiplier with two 4-bit inputs and an 8-bit result... probably. If you have *lots* of 16V8s on a board, you could make a bigger multiplier. When I did a Google search for GAL16V8, the first hit I found was the Lattice data sheet. (I used to know those devices inside-out, but I haven't used one for so long that I thought I'd better remind myself of the details.) Not a bad place to start. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 125971
On Nov 10, 10:49 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sat, 10 Nov 2007 18:25:35 -0000, Amit <amit.ko...@gmail.com> wrote: > > >Hello group, > > >I'm new to this field and currently learning how 16v8 architecture is > >designed. Of course, pretty confused but as my first experiement I > >need to implement a logical function and also design multiplier using > >61v8. > > >does anybody know where I can get some information to be able to > >complete this? > > A GAL16V8, which I guess is what you mean, has only... > - 8 bits of storage > - 18 user I/O pins, of which one must be taken as a clock > in most cases > so your multiplier surely cannot be very big! You could make > a multiplier with two 4-bit inputs and an 8-bit result... > probably. If you have *lots* of 16V8s on a board, you > could make a bigger multiplier. > > When I did a Google search for GAL16V8, the first hit I found > was the Lattice data sheet. (I used to know those devices > inside-out, but I haven't used one for so long that I thought > I'd better remind myself of the details.) Not a bad place to start. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Hello Jonathan, Thanks for your response. you are right, I did download it but one thing that I need to know how can I find a right flow? and associate it with a multiplier 4 by 4? it seems there are other controlling inputs such as Vcc (or maybe I'm wrong) but is there any example of an adder for instance? Once again thanks. amitArticle: 125972
On Nov 9, 10:56 pm, Readon <xydarc...@gmail.com> wrote: > On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote: > > > > > > > On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote: > > > > On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote: > > > > > On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote: > > > > > > i want to read & write data to/from a fifo placed in fpga. MCU's > > > > > external bus is connected to the chip. I am using the sync-fifo ip of > > > > > Altera CycloneII. The data bus and control signal are connected to > > > > > fifo directly. it's unfortune that when i read once from bus, data > > > > > would be read twice from fifo because there are two clock rising edges > > > > > during read signal(low active) is resetted. I think it will read more > > > > > datas from fifo if the read signal is resetted long enough. > > > > > Is there any good design for fifo interface connecting on the > > > > > exteranl bus? > > > > > Using a Synchronous FIFO implies that the read clock and the write > > > > clock are in the same clock domain. Is your MCU supplying the FIFO's > > > > clock or is the FPGA supplying the MCU's clock? If the clock sources > > > > are different, then you either need an Asynchronous FIFO, or you need > > > > to run the MCU and FPGA from the same clock. > > > > HTH > > > > -Dave Pollum > > > > It is in different clock, i tried altera's asynchronous FIFO which > > > need two extra clock for reading. > > > is there any better solution? > > > If your MCU is running much slower than the FPGA, you can use the > > FPGA's internal clock to run the synchronous FIFO, and a little > > state logic to generate the necessary (single cycle) pulses for > > read and write from the MCU interface signals. > > unfortunately, the problem i met is on the contrary. MCU is much > faster then FPGA, about 4 times.- Hide quoted text - > > - Show quoted text - Some how you need to synchronize your MCU read to the FIFO read clock (edge detect as others said), then make sure the read connects to the FIFO has 1 clock wide only btw, building your own FIFO isn't difficult if the speed fairly "slow"Article: 125973
Mike Treseler <mike_treseler@comcast.net> writes: >> My opinion is that the proprietary closed nature of FPGA hardware >> and software tools is the big obstacle in this way. Yes. > If I had a great idea in this area, I would demonstrate it in > simulation and then ring up a venture capitalist. If every beneficial technology were commercially exploitable by a small startup company I think the computing world would be quite a different place. - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 125974
In article <b66e6525cd1c8c9f136acf9d755@news.ks.uiuc.edu>,
Matthew Hicks <mdhicks2@uiuc.edu> wrote:
>In FPGAs, configurations can be stored in Flash in an encrypted format that
>only the FPGA to be configured has the key to . During configuration, the
>FPGA does the encryption, so even data over the Flash to FPGA channel is
>secure. How the FPGA keeps it's key secure, I don't remember. Maybe there
>is an analogue to this in MCU land.
Specifically Altera Statrix-II FPGAs have AES 128 decryption and OTP (fuse)
non-readable key storage for the configuration bitstream.
So: run Linux on a NIOS soft core in one of these FPGAs. Encrypt the code
in flash. Add decryption units with keys to the memory interfaces (or limit
yourself to the memory built into the FPGA). The decyption unit and keys
are encrypted in the Stratix-II bitstream, so they can't be read.
Even if you were able to read the fuse settings somehow, you would then have
to reverse-engineer the undocumented bit-stream format.
I think this is all bad, except for protecting nuclear weapons. There would
be no hacked iPhones if its firmware was encrypted this well. Vernor
Vinge's _Rainbow's End_ told about a computer engineer who could no longer
tinker with hardware due to her invention of a secure hardware environment.
--
/* 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]]);}
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