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 Aug 29, 9:44 am, John_H <newsgr...@johnhandwork.com> wrote: > Gabor wrote: > > > While the Lattice ECP does not have the SERDES blocks in the I/O, > > you can run fairly high data rates with their DDR input flops using > > the IDDRX2B "2x geared" primitive. Only the edge clock has to > > run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2 > > of that speed (1/4 the bit rate) getting 4 bits on every rising edge. > > > You can see this in the 7:1 serdes reference design (I use this > > for Channel-Link at 85 MHz = 595 Mbps). I should also add > > that I use LVDS for these data rates. > > > Regards, > > Gabor > > Thanks for that info! I managed to miss that capability when I went > through the data sheet. It may be time for me to reread the info on the > part I'm now designing with: an ECP2M. > > The Lattice I/Os (faster speed grade, of course) are rated at 840 Mb/s > which would need a clock of only 210 MHz for the IDDR2XB which should be > quite capable in those devices. > > The ECP2 family even has 144 pin tqfp and 208 pin pqfp packages. > > That would really be a superb device for this problem. > > - John_H You may want to watch out for the TQ and PQ packages. I have had issues with SSO (ground bounce) using the TQ144 for the 7:1 serdes unless I carefully controlled output switching. I have had no problems with the 256 BGA parts. Also be aware of pin noise sensitivity issues listed in TN1159. I added a number of virtual grounds to help this.Article: 134776
"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message news:2fc35801-55fe-4fa0-81c2-91bf15ca1cb6@e39g2000hsf.googlegroups.com... > On 28 Aug., 18:24, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > >> > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a >> > soft-core, to me, it's the same as linking with a library. >> >> If that were so, Genode would be required to GPL Microblaze, and our >> troubles would already be solved. We would just refer everyone else to >> Genode for the Microblaze code. > > No. GPL prohibits linking with non GPL code, that is a fact. Compiling > an > FPGA bitstream that contains both Genode and non GPL Xilinx Cores is > therefore a violation of Genodes GPL license. > This does not mean that the Xilinx Cores suddenly fall under the GPL. > It only means that the creators of Genode do not allow you to create > such a > bitstream. (Violators face multiple years in prison in most > countries.) That's pretty messed up. Are you stating it as an authoritative interpretation of the GPL? Or are you, like me, musing about its possible meaning? >From GPL3: [[ The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. ]]Article: 134777
In article <48B30324.2000603@wustl.edu>, Jon Elson <elson@wustl.edu> wrote:
>Hello, all,
>
>I just got a potential project thrown in my lap. I designed an
>all-analog delay generator module, with 32 delays that trigger 32 pulse
>widths. So, basically, 64 wide-range programmable one-shots on one
>board. LVDS in, ECL out (for legacy gear). These one-shots can be
>programmed from about 10 ns to 12 us in several ranges.
Why not use time delay vernier chips for this, for example SY604 or AD9501?
--
/* 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: 134778I've recently started using MPPR to try and get better timing results. I know there are a lot of "better" way to do it, but if I can MPPR over a weekend and get the results I need - that's easy and good enough for me. It seems to me that MPPR is critically flawed in that it only operated on the results of one specific Map. If the Map seed isn't a very good one, all MPPR results will be poor. Is there anyway to get MPPR to vary the Map seed too? Or, better yet, is there a "multipass Map" that you could use to get a really good Map before going to PPR? Thanks DanArticle: 134779
OK thanks John, Peter, Gabor. I guess I plow ahead and wait for a timing issue. John, I'm not sure what you mean by a binary tree. If you mean the outputs of muxes going into the input of a next layer mux, then I would suspect that the synthesizer is already doing that. I suppose I could explicitly write those muxes, grouping what I think might be the best routing. I should probably get rid of my if, elsif constructions to avoid any kind of priority coding. I have seen where the anti-if condition is routed forward to the next if slice. A clean way of handling the synthesis, but might make for a long chain. That's not for the counters but for the memory data output. I am considering using the BRAM as Peter suggest. The BRAM has huge nearly-free muxing capability. But some of my data I collect is fast and some of the data going out to the fabric really needs to be there all the time. I don't know what the tradeoff between having everthing in the fabric or having BRAM with copies of the faster items in fabric. Yeah Gabor, I have I2C stuff to but right now I don't fiddle with the constants in real time. Brad AiVisionArticle: 134780
On Aug 29, 3:10 pm, "Dan K" <danielgkNOS...@visi.com> wrote: > I've recently started using MPPR to try and get better timing results. I > know there are a lot of "better" way to do it, but if I can MPPR over a > weekend and get the results I need - that's easy and good enough for me. > > It seems to me that MPPR is critically flawed in that it only operated on > the results of one specific Map. If the Map seed isn't a very good one, all > MPPR results will be poor. Is there anyway to get MPPR to vary the Map seed > too? Or, better yet, is there a "multipass Map" that you could use to get a > really good Map before going to PPR? > > Thanks > > Dan Which version of ISE are you running? The map settings for earlier versions needed to have "Timing-based Packing and placement" turned off for a meaningful multipass run. For 10.1i I know you can set the placement table entry when you enable the timing- based placement for Map, but I don't know if you can run multi- pass Map + place + route without writing a Tcl script.Article: 134781
On 29 Aug., 18:37, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > "Kolja Sulimma" <ksuli...@googlemail.com> wrote in message One essential question is what "the work" is in this case. To me it is pretty clear that the bitstream is the work. The work can't be only part of the bitstream, because the parts can't be seperated easily. The IP inside a bitstream has a much tighter coupling than statically linked code has. It could be more than the bitstream (e.g. including the board schematics and layout), because of the "major component" clause that you cite as there generally is no publicly available implementation that allows to run your bitstream. As you cite "[the source] does not include [stuff] which are not part of the work." GPL requires available sourcecode for everything that is part of the work. The reason for the LGPL to exist ist that sometimes this approach is not practical and you need to allow components in the work that are covered by other licenses. If that was possible with the GPL the LGPL would be redundant. KoljaArticle: 134782
On Aug 29, 9:41 pm, already5cho...@yahoo.com wrote: > On Aug 29, 2:58 pm, MooseFET <kensm...@rahul.net> wrote: > > > > > On Aug 28, 9:50 pm, already5cho...@yahoo.com wrote: > > > > On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote: > > > > > On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > > > > > > MooseFET wrote: > > > > > > On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > > > > > >> Even with FPGAs the code can be quite portable. Usually quite small > > > > > >>... > > > > > > I have never seen a case of FPGA code going between Xilinx's tools and > > > > > > Altera's without some very serious rewriting. > > > > > > Then you have something wrong in your coding style. Normally if some > > > > > portability is taken into consideration during design, porting takes > > > > > few days to get first impressions. > > > > > I wasn't referring to just my code when I said "seen". > > > > > Do you use the assignment of the "Z" value to cause a tri-state? > > > > Quartus doesn't compile them. > > > > When you assign "Z" to external pin - Quartus compiles it very well, > > > thank you. > > > Have you done it? > > Of course. > > > I am surprised if they have fixed it. I had to > > recode to use the tri() to get the tri-state pins to work. I had > > defined a component with the tristate pins that I connected directly > > to the pins of the chip. The compiler would choke on it. The same > > code compiled on Cypress's "warp" and produced exactly the tristated > > pin I expected. > > Did your component had tristate pins defined as out or inout? IIRC: Some were inout because they were bidirectional to the same part. Others were outputs of one part but inputs to another. This was a data bus situation. I had two Cygnal F124 CPUs and a DMAed input sharing 512K * 8 RAM. The result was that I needed two 8 bit true I/O busses and a MUXed bus at the RAM. > The later, indeed, had problems until relatively recently but the > former always worked as expected. > I, personally, always prefer to have separate in and out ports in > internal components, so I wasn't hit by earlier bugs. > > Why they fixed it at the end? I think, the main reason was SOPC > builder. They wanted the same SOPC builder output to work both as a > top level project and as a component so they had little choise. > Hopefully, by now, they realized that except for the toy problems no > sane developer will use SOPC builder output as a top level but the > inout fix is done already and there are no reason to go back. > > > > On the other hand, internal tristate nodes are not supported by Altera > > > architecture - how would you expect Quartus to synthesize them in this > > > case? Infer muxes? > > > I didn't do this but yes a compiler could easily turn it into > > something like this to send to the fitter: > > > Y = X1 & EN1 # X2 & EN2 # X3 & EN3; > > > There is no need to make a full mux because there should only be one > > assignment of a non-Z value at a time and thus only one EN# would be > > true. > > As I said in another post, nobody here codes this way so I have no > idea whether the compiler does the right thing. > > P.S. > I added comp.arch.fpga to the list. Let's see the opinion of real > experts.Article: 134783
I am using Matlab to communicate with the serial port and the other end is connected to the FPGA. I am writing data into the serial port and reading it after a pause which is equal to the time taken by the data to go to the FPGA and back. I am dividing the image to packets and sending it in bursts. I am getting a TIME OUT ERROR in matlab. It comes sometimes but not always. I tried increasing the timeout but it doesnt work. Could someone please tell me if this is an interface issue. Do you think C is a better interface? ThanksArticle: 134784
"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message news:12661994-eb63-4839-bc34-5287f85a4c87@y38g2000hsy.googlegroups.com... > On 29 Aug., 18:37, "MikeWhy" <boat042-nos...@yahoo.com> wrote: >> "Kolja Sulimma" <ksuli...@googlemail.com> wrote in message > > > One essential question is what "the work" is in this case. To me it is > pretty clear > that the bitstream is the work. The work can't be only part of the > bitstream, because > the parts can't be seperated easily. The IP inside a bitstream has a > much tighter coupling > than statically linked code has. > > It could be more than the bitstream (e.g. including the board > schematics and layout), > because of the "major component" clause that you cite as there > generally is no > publicly available implementation that allows to run your bitstream. Separating "the work" from the bitstream is conceptually no more difficult than deleting or uninstalling an application from a harddrive. From the user's point of view, the file's location and representation on a harddrive is equally opaque as it is inside a bitstream. The work's presence in a bitstream does not introduce new concepts or difficulties in regards GPL. I read the GPL to cover no more than the .ELF which includes my custom code, and the supplied display IP along with my derived enhancements. Their inclusion in the bitstream is incidental in the same way that a device driver or application is incidental when present in the boot image of a general purpose computer. The presence of a proprietary operating system and other components in the boot image in no way violates the GPL terms for using or distributing that device driver or application. The presence of other IPs in the same bitstream does not violate the terms or intent of the GPL for Genode. By way of example, suppose I write an application that reads Excel spreadsheets, and displays its results using a GPL'ed library. I would like to distribute the application under LGPL terms. However, the additional permissiveness is meaningless, because the GPL library would not be available to those wishing to produce a proprietary derived work. Otherwise, my choices have absolutely no implications for any of the involved components, including the GPL'ed library, Excel, and Windows. Similarly, if I build a signal processing system and use GPL'ed Genode for user interaction, I am bound by Genode's GPL terms, which prohibits proprietary use. However, GPL has no implications for the proprietary Ethernet or PCI IP's used elsewhere in the system. I'll submit that a system consisting only of Genode in its bitstream is of no practical use to anyone or application. The stated intent of the GPL is to induce free developemnt and distribution by limiting use of covered works to only non-proprietary applications. It would be utterly self-defeating to pre-suppose that eventually someone will build a free board design and develop free IP around its use, to permit its use. > As you cite "[the source] does not include [stuff] which are not part > of the work." > GPL requires available sourcecode for everything that is part of the > work. > > The reason for the LGPL to exist ist that sometimes this approach is > not practical > and you need to allow components in the work that are covered by other > licenses. > If that was possible with the GPL the LGPL would be redundant. The LGPL differs mainly by permitting use and distribution in proprietary systems, while the GPL does not. Perhaps this is the author's intent; perhaps it is not. It would be duplicitous to coerce him into this direction under the guise of reasonable use, when the GPL already sufficiently allows its use, presuming for the moment that it does and that this is his intent. Bear in mind my layman status in the opinions above. I too would very much like to hear authoritative clarification (although the license wording seems reasonably clear already).Article: 134785
On 30 Aug., 07:41, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > "Kolja Sulimma" <ksuli...@googlemail.com> wrote in message > > I read the GPL to cover no more than the .ELF which includes my custom co= de, > and the supplied display IP along with my derived enhancements. Their > inclusion in the bitstream is incidental in the same way that a device > driver or application is incidental when present in the boot image of a > general purpose computer. But a propriatary EDK project is no general purpose computer. I agree, that if you have a pure software project you could probably treat it as a seperate work from the hardware design. (That's what it is all about: What constitued "the work".) But as the hardwarearchitecture you are running it on is proprietrary you also must supply at least the edk system definition files. "The =93Corresponding Source=94 for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code." [...] "However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. " See the formulation "generally available" which does not hold for your own EDK design. The GPL is about anybody beeing able to recreate the work. Someone who wants to do that might need to spend some money (e.g. buying EDK) but you can't require them to do reverse engineering on the hardware architecture it is running on. Kolja SulimmaArticle: 134786
Hi group. I'm about to embark on a final year project for my University course, and since I have a reputation for too-ambitious projects, thought that I'd ask how 'straightfoward' this task would be here, before I decide finally. My main idea at the moment is an encrypting DIMM module, intended to protect against 'cold boot' attacks, and the scenario that an attacker is presented with a freshly-turned-off machine with some juicy secret still in a DIMM module, which they can then remove, throw in to some socket, and dump. My intent is to XOR-encode memory (using a suitably large key and some yet-to-be-thought-up scheduling algo to prevent against predictable null plaintext weaknesses) in an FPGA on-the-fly before writing/ reading main DRAM. I was planning to implement 'proper' strong crypto, but don't really think it's practical to encrypt/decrypt data fast enough. I'm planning on working a generation or two behind current technology, with either 133MHz SDR or DDR parts. I haven't worked with DRAM at this low a level before, but am hoping that I can fit CL3 DRAMs to my module, instruct the BIOS to use CL2 (perhaps through some bodging of the SPD), and use the resultant 'spare' cycle to do my XOR'ing. Does this sound plausible, or would it only really be practical/possible to use faster DRAMS to do as I describe? Another thought I've had is to tell the BIOS that I'm running registered DIMM modules, and generate the necessary 'spare' clock that way, with the register being in my FPGA logic, and using a DLL/PLL to ensure that I've got enough time to select a key, and xor it (I don't envision needing more than 2 clocks - say 4 for safety). Does this sound more plausible? Would the only 'practical' way to do all this be to use DDR DRAM chips (and associated power/etc cleverness) on an SDR board? I don't like that idea, it sounds scary :) Also, I'm kind of apprehensive about laying out a board for this. I'm pretty inexperienced in PCB design, but have the University library (not to mention their EE department staff!) to help, so I figure it shouldn't be too bad. How complex a board design would this be, subjectively speaking? And my last question - I'm thinking of using a Spartan 3 for this. I can't think of any reason it'd require anything beefier such as a Virtex - can any of you? I'm fairly neutral in terms of vender A or X, but more experienced with X parts. Having said that, I'm not doing anything terribly complex in terms of logic (am I?) Thanks for reading, and yes, I should be talking to the Uni instead of the Internet about this - but term hasn't started yet, and I'm trying to be really organised this year... - Alan H.Article: 134787
<randomdude@gmail.com> wrote in message news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com... > My main idea at the moment is an encrypting DIMM module, intended to > protect against 'cold boot' attacks, and the scenario that an attacker > is presented with a freshly-turned-off machine with some juicy secret > still in a DIMM module, which they can then remove, throw in to some > socket, and dump. Perhaps the first order of business is to establish that this is a viable attack. Can someone really do that? SDRAM refresh cycles are on the order of <10 usec, otherwise data would be lost. I would think much simpler and more severe "attacks" would be available once you gained physical control of the machine. Cutting out the living and still beating heart idea tops them all in complexity.Article: 134788
On Sep 1, 4:52=A0am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > <randomd...@gmail.com> wrote in message > > news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com... > > > My main idea at the moment is an encrypting DIMM module, intended to > > protect against 'cold boot' attacks, and the scenario that an attacker > > is presented with a freshly-turned-off machine with some juicy secret > > still in a DIMM module, which they can then remove, throw in to some > > socket, and dump. > > Perhaps the first order of business is to establish that this is a viable > attack. =A0Can someone really do that? SDRAM refresh cycles are on the or= der > of <10 usec, otherwise data would be lost. I would think much simpler and > more severe "attacks" would be available once you gained physical control= of > the machine. Cutting out the living and still beating heart idea tops the= m > all in complexity. Yup, apparently so. See http://citp.princeton.edu/memory/ :)Article: 134789
<randomdude@gmail.com> wrote in message news:b24b1f24-0ecb-4eb1-8193-26bdc61a1ff9@73g2000hsx.googlegroups.com... On Sep 1, 4:52 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > <randomd...@gmail.com> wrote in message > > news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com... > > > My main idea at the moment is an encrypting DIMM module, intended to > > protect against 'cold boot' attacks, and the scenario that an attacker > > is presented with a freshly-turned-off machine with some juicy secret > > still in a DIMM module, which they can then remove, throw in to some > > socket, and dump. > > Perhaps the first order of business is to establish that this is a viable > attack. Can someone really do that? SDRAM refresh cycles are on the order > of <10 usec, otherwise data would be lost. I would think much simpler and > more severe "attacks" would be available once you gained physical control > of > the machine. Cutting out the living and still beating heart idea tops them > all in complexity. Yup, apparently so. See http://citp.princeton.edu/memory/ :) --------- Thanks. In regards your original question, if viability encompasses usability, the huge power footprint is a problem. Simpler, less intrusive solutions are likely possible. For example, drawing down the residual charge in the memory cells will also render their old contents inaccessible.Article: 134790
MikeWhy wrote: > "Kolja Sulimma" <ksulimma@googlemail.com> wrote in message > news:2fc35801-55fe-4fa0-81c2-91bf15ca1cb6@e39g2000hsf.googlegroups.com... >> On 28 Aug., 18:24, "MikeWhy" <boat042-nos...@yahoo.com> wrote: >> >>> > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a >>> > soft-core, to me, it's the same as linking with a library. >>> >>> If that were so, Genode would be required to GPL Microblaze, and our >>> troubles would already be solved. We would just refer everyone else to >>> Genode for the Microblaze code. >> >> No. GPL prohibits linking with non GPL code, that is a fact. Compiling >> an >> FPGA bitstream that contains both Genode and non GPL Xilinx Cores is >> therefore a violation of Genodes GPL license. >> This does not mean that the Xilinx Cores suddenly fall under the GPL. >> It only means that the creators of Genode do not allow you to create >> such a >> bitstream. (Violators face multiple years in prison in most >> countries.) > > That's pretty messed up. Are you stating it as an authoritative > interpretation of the GPL? Or are you, like me, musing about its > possible meaning? > The GPL is a license based on copyright laws - I don't believe you can face "multiple years in prison" for breaking it. My understanding (IANAL) is that you will need to be at the level of serious economic crime before it becomes a criminal offence, and thereby risk jail. The normal result of court cases around the GPL is that the violator must stop violating (i.e., remove the code from their product, or make all the required GPL'ed code available), promise not to violate the GPL in the future, and pay some monetary compensation. That's been testing in courts in a number of countries, although AFAIK that's only been for complete works (such as busybox) rather than testing the meaning of "derived works" or "linking" in court. It's also important to note that the GPL covers distribution only - you are perfectly within your rights to mix and match GPL'ed code with any other code you like (assuming the other code's license is okay with this), as long as it is for your own use or use inside your organisation. You only have to consider the GPL when distributing the code. The GPL3 excerpt you quoted is in the GPL3, but not the GPL2 - it's one of the differences, and that makes it important to know which GPL version is under consideration (if code uses a standard GPL of any version, you can "upgrade" it to a newer version if you want). Does the Microblaize count as a "system library" in an FPGA? I believe (my own thoughts) that in an FPGA design, generating and compiling modules is equivalent to compilation in software, and routing and placing is equivalent to static linking. If there are components that are isolated and communicate through standard and fixed interfaces, then it could be argued that these are separate "works" and not part of a complete "derived work", and the GPL/LGPL will not spread across the interface. But the opposite could also be argued - the router and placer software will dig into components on each side of the interface, and the implementation of these components will depend on each other. This of course gives you a more efficient bitstream - but it means that the final bitstream cannot be split into separate parts and is therefore a single combined "work". All in all, I would not distribute an FPGA design which includes GPL or LGPL code without an explicit statement from the copyright owner saying exactly how they interpret the GPL in this case. > From GPL3: > > [[ The “System Libraries” of an executable work include anything, other > than the work as a whole, that (a) is included in the normal form of > packaging a Major Component, but which is not part of that Major > Component, and (b) serves only to enable use of the work with that Major > Component, or to implement a Standard Interface for which an > implementation is available to the public in source code form. A “Major > Component”, in this context, means a major essential component (kernel, > window system, and so on) of the specific operating system (if any) on > which the executable work runs, or a compiler used to produce the work, > or an object code interpreter used to run it. > > The “Corresponding Source” for a work in object code form means all the > source code needed to generate, install, and (for an executable work) > run the object code and to modify the work, including scripts to control > those activities. However, it does not include the work's System > Libraries, or general-purpose tools or generally available free programs > which are used unmodified in performing those activities but which are > not part of the work. For example, Corresponding Source includes > interface definition files associated with source files for the work, > and the source code for shared libraries and dynamically linked > subprograms that the work is specifically designed to require, such as > by intimate data communication or control flow between those subprograms > and other parts of the work. > > ]] >Article: 134791
On Sun, 31 Aug 2008 15:58:54 -0700 (PDT), randomdude@gmail.com wrote: >Hi group. > >I'm about to embark on a final year project for my University course, >and since I have a reputation for too-ambitious projects, thought that >I'd ask how 'straightfoward' this task would be here, before I decide >finally. > >My main idea at the moment is an encrypting DIMM module, intended to >protect against 'cold boot' attacks, and the scenario that an attacker >is presented with a freshly-turned-off machine with some juicy secret >still in a DIMM module, which they can then remove, throw in to some >socket, and dump. > >My intent is to XOR-encode memory (using a suitably large key and some >yet-to-be-thought-up scheduling algo to prevent against predictable >null plaintext weaknesses) in an FPGA on-the-fly before writing/ >reading main DRAM. I was planning to implement 'proper' strong crypto, >but don't really think it's practical to encrypt/decrypt data fast >enough. Maybe if you were encrypt the address instead of the data, that might give you a little more time to handle things. The end result should be pretty much the same. It also means you can treat reads and writes the same, and have far fewer signals to intercept, simplifying your PCB layout task. ..of course if the aim is to counter removal, maybe a much simpler approach would be something that detects removal and erases the memory.Article: 134792
On 1 sept, 12:28, Mike Harrison <m...@whitewing.co.uk> wrote: > On Sun, 31 Aug 2008 15:58:54 -0700 (PDT), randomd...@gmail.com wrote: > >Hi group. > > >I'm about to embark on a final year project for my University course, > >and since I have a reputation for too-ambitious projects, thought that > >I'd ask how 'straightfoward' this task would be here, before I decide > >finally. > > >My main idea at the moment is an encrypting DIMM module, intended to > >protect against 'cold boot' attacks, and the scenario that an attacker > >is presented with a freshly-turned-off machine with some juicy secret > >still in a DIMM module, which they can then remove, throw in to some > >socket, and dump. > > >My intent is to XOR-encode memory (using a suitably large key and some > >yet-to-be-thought-up scheduling algo to prevent against predictable > >null plaintext weaknesses) in an FPGA on-the-fly before writing/ > >reading main DRAM. I was planning to implement 'proper' strong crypto, > >but don't really think it's practical to encrypt/decrypt data fast > >enough. > > Maybe if you were encrypt the address instead of the data, that might give you a little more time to > handle things. The end result should be pretty much the same. > It also means you can treat reads and writes the same, and have far fewer signals to intercept, > simplifying your PCB layout task. > > ..of course if the aim is to counter removal, maybe a much simpler approach would be something that > detects removal and erases the memory. really bad suggestion ;) the bus width is 8 bytes, now we also need handle burst writes so we only can change (crypt) adress on the max burst size boundary, leaving LARGE portions of the data unmodified, larger then is needed to hold credit card numbers and other information.. erasing the memory is also not an option, because the erase circuitry will be disabled by the attacker and it takes too long anyway and the data encryption must also be done right or it is of no use if the key is not hold in volatile self desctructable memory, and the module HAS to deal with tampering, means it has to be powered on ALL the time. wrong :) the module has to GENERATE new keys each time it is powered on and it has to DESTRUCT that key on tamper attempt or power change so it must be alive just a little after power removal. security above entry level isnt so easy anymore at all Antti PS the RAM retention is really an issue, I have used ram dumps done AFTER power off cycle for debugging myself, usually with 0 bad bits captured.Article: 134793
>I should probably get rid of my if, >elsif constructions to avoid any kind >of priority coding. I have seen where >the anti-if condition is routed forward >to the next if slice. A clean way of >handling the synthesis, but might make >for a long chain. That's not for the >counters but for the memory data output. For inferring multiplexers, use a 'case' statement (in VHDL - I can't remember the equivalent Verlog syntax, and can't be bothered to look it up!).Article: 134794
I just wanted to make a smalll change so launched EDK 9.2 (poroject was done with 9.2) but no luck EDK happily report it FOUND cygwin (why should it say that? I dont wannt know it, as i want EDK not cygwin!) when i tried to build the project it says CAN NOT USE cygwin NEWER than 1.24 !? does it really mean taht EACH EDK/ISE version has ot be canned into special VM virutal machine with the set of CORRECT cygwin version, etc....? ?? maybe there sis some hidden switch to enable cygwin newer than 1.24 or?? i havent touched Xilinx tools for a 2 months maybe now after 2 minutes I am already frustrated Xilinx wants to be THE leading FPGA company they defenetly lead with shitty software and frustrated customers AnttiArticle: 134795
On Sep 1, 7:28=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > I just wanted to make a smalll change so launched =A0EDK 9.2 (poroject > was done with 9.2) > but no luck EDK happily report it > FOUND cygwin (why should it say that? I dont wannt know it, as i want > EDK not cygwin!) > > when i tried to build the =A0project it says CAN NOT USE cygwin NEWER > than 1.24 !? > > does it really mean taht EACH EDK/ISE version has ot be canned into > special VM virutal machine > with the set of CORRECT cygwin version, etc....? ?? > > maybe there sis some hidden switch to enable cygwin newer than 1.24 > or?? > > i havent touched Xilinx tools for a 2 months maybe > now after 2 minutes I am already frustrated > > Xilinx wants to be THE leading FPGA company > they defenetly lead with shitty software and frustrated customers > > Antti The problem w/ EDK is that it uses Cygwin to emulate a POSIX environment under windows. You can blame that one on Billy Gates. When you install EDK it will detect if you have Cygwin already installed. If it finds it, it won't use its own version and just use the one you have. I think that's a nice feature. I'd rather not have 10 different copies of Cygwin running around :P. Problem is that version of the Cygwin tools that ship with EDK were built for an older version of Cygwin. As such, if you have a newer version installed you can run into version compatibility issues. In the previous versions of EDK, it just used it and you had to guess why they failed. Right now my EDK 9.2 is using the Cygwin installed by EDK 9.1.Article: 134796
Hi, In a fairly large design I am doing some debugging on the system board directly. When I discover a mistake and modify the vhdl code, the whole design goes through synthesis and place-and-route. Many parts of the design are never touched by my modifications, and I wonder if it is possible to speed up the debug-modify-compile loop by setting up my project in such a way that only the modified parts need to go through the compile loop. The places I modify are typically inside entities that are instantiated on the top-level, so in my opinion this should be possible, but I do not know the tool, ISE 10.1, well enough to know where to set the right flags. It is kind of irritating to wait for 5 minutes to compile just because I insert an inverter. The really big things are generated with coregen anyway so I am not supposed to change anything in those modules anyway. Will be perfectly happy with a link to documentation to read as I am not that familiar with the ISE tool yet. -- SvennArticle: 134797
On 1 sept, 16:09, morphiend <morphi...@gmail.com> wrote: > On Sep 1, 7:28=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > I just wanted to make a smalll change so launched =A0EDK 9.2 (poroject > > was done with 9.2) > > but no luck EDK happily report it > > FOUND cygwin (why should it say that? I dont wannt know it, as i want > > EDK not cygwin!) > > > when i tried to build the =A0project it says CAN NOT USE cygwin NEWER > > than 1.24 !? > > > does it really mean taht EACH EDK/ISE version has ot be canned into > > special VM virutal machine > > with the set of CORRECT cygwin version, etc....? ?? > > > maybe there sis some hidden switch to enable cygwin newer than 1.24 > > or?? > > > i havent touched Xilinx tools for a 2 months maybe > > now after 2 minutes I am already frustrated > > > Xilinx wants to be THE leading FPGA company > > they defenetly lead with shitty software and frustrated customers > > > Antti > > The problem w/ EDK is that it uses Cygwin to emulate a POSIX > environment under windows. You can blame that one on Billy Gates. > > When you install EDK it will detect if you have Cygwin already > installed. If it finds it, it won't use its own version and just use > the one you have. I think that's a nice feature. I'd rather not have > 10 different copies of Cygwin running around :P. Problem is that > version of the Cygwin tools that ship with EDK were built for an older > version of Cygwin. As such, if you have a newer version installed you > can run into version compatibility issues. In the previous versions of > EDK, it just used it and you had to guess why they failed. > > Right now my EDK 9.2 is using the Cygwin installed by EDK 9.1. Yeah, I know the old "blame bill gates" excuse, but there are companies who are able to ship WORKING software no matter the posix and billgates whining if EDK can scope with cygwin 1.25 it should provide an option to select an alternative version, or for heavens sake even downgrade the current one, what ever, it must be able to WORK once it is able to start. software is expected to work, not make customers unhappy AnttiArticle: 134798
On Sep 1, 8:21=A0am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > <randomd...@gmail.com> wrote in message > > news:b24b1f24-0ecb-4eb1-8193-26bdc61a1ff9@73g2000hsx.googlegroups.com... > On Sep 1, 4:52 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > > > > > <randomd...@gmail.com> wrote in message > > >news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com..= . > > > > My main idea at the moment is an encrypting DIMM module, intended to > > > protect against 'cold boot' attacks, and the scenario that an attacke= r > > > is presented with a freshly-turned-off machine with some juicy secret > > > still in a DIMM module, which they can then remove, throw in to some > > > socket, and dump. > > > Perhaps the first order of business is to establish that this is a viab= le > > attack. Can someone really do that? SDRAM refresh cycles are on the ord= er > > of <10 usec, otherwise data would be lost. I would think much simpler a= nd > > more severe "attacks" would be available once you gained physical contr= ol > > of > > the machine. Cutting out the living and still beating heart idea tops t= hem > > all in complexity. > > Yup, apparently so. Seehttp://citp.princeton.edu/memory/:) > > --------- > Thanks. > > In regards your original question, if viability encompasses usability, th= e > huge power footprint is a problem. Simpler, less intrusive solutions are > likely possible. For example, drawing down the residual charge in the mem= ory > cells will also render their old contents inaccessible. Hum, thanks - I hadn't thought of it in terms of power budget (I guess that shows my inexperience!). I'll look in to that in depth. What kind of less-intrusive solutions do you mean, though? How would you lower the residual power in each cell? The obvious way it to overwrite RAM with zeros on power-on, but this would be mitigated by transplanting the DIMM in question to another machine (or a custom board). On Sep 1, 11:04 am, Antti <Antti.Luk...@googlemail.com> wrote: > > and the data encryption must also be done right or it is of no use > if the key is not hold in volatile self desctructable memory, and the > module HAS to deal with tampering, means it has to be powered > on ALL the time. wrong :) > the module has to GENERATE new keys each time it is powered on > and it has to DESTRUCT that key on tamper attempt or power change > so it must be alive just a little after power removal. > Antti My plan was to store the key in the FPGA - block RAM, flipflops, or some such - where it would be destroyed at poweron by the GSR pulse, and would cause an attacker to need to disassemble the FPGA itself and use some electron wizardry at the die level. Am I right in this belief? Actually, my plan was to use a custom BIOS (ie, openBIOS/coreboot) to send a user-supplied key to the module on each poweron, from keyboard or some removable device. This does entail some extra work, though, and your suggestion of generating a key on each boot sounds a lot better - I can whack some 'pretty random number source' chip on the module and use it as a key source. Thanks!Article: 134799
Hello all, I am looking to find information/books in Camera design with CCD and FPGA. till now i havent find any. Have you something spotted? regards
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