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
Walter Banks wrote: > > Jim Granville wrote: > > >>The tiniest CPUs do not need a stack, and interupts do not need to be >>re-entrant, so a faster context switch is to re-map the Registers, Flags >>(and even PC ? ) onto a different area in BRAM. >>You can share this resource by INTs re-map top-down, and calls re-map >>bottom up - with a hardware trap when they collide :) > > > Once you get into seeing clearly the relationship between features and > cost a lot can be removed. > > Interrupts can be removed at extremely low cost to applications. Both the > Microchip PIC12 and Freescale RS08 do not have interrupts. In the > RS08 C compiler we developed some software IP to where possible > go into a power down mode and launch execution threads that compiled as > execution to completion. > > The threads are typically short and a as a side effect run to completion > makes local re-use easy > > C compilers implemented for small processors work well with out either > a data or subroutine return stack. Two of the processors we have written > compilers for in the last couple years both used an assessable return > register. Flow control analysis in the compiler make nested subroutines > user transparent. > > The instruction set reduction in the RS08 from the S08 parent had a > 4-6% impact on application performance. > > Walter.. Hi Walter, Have you ever thought about doing a Compiler+FPGA_CPU (+Sim+Debug?) bundle ? -jgArticle: 107026
burn.sir@gmail.com wrote: > contsains "only" 2**64 keys, yes it can be cracked... but I am pretty sorry, make that 2**60. Of course, a professional cryptographer could get that down to 2**10 or so in matter of minutes Speaking of those shady types, I happen to know a really good one. I can ask him for help in exchange for that EP2S60 board ;) (kidding, kidding. besides, who wants a FPGA that is not supported in the QII webpack?) -BurnsArticle: 107027
burn.sir@gmail.com wrote: > hypermodest wrote: > I got a few questions for you: > > 1st: do you really need to brute force it? I have no other idea :) > 2nd: how much time do you got? Let's say, one week.. > 3rd: budget? I assume you are not working for NSA or similar YAT (Yet > Another TLA) Between $1k and $2k. > 4th: do you really have the ambition to learn FPGA development for a > simple homework? Yes, FPGA is really interesting area for me. > Given the simplicity of the algorithm and given that your search space > contsains "only" 2**64 keys, yes it can be cracked... but I am pretty > sure that your simple hash function can be cracked by other means than > brute force. You're probably right. But good and modern crypto hash-functions are designed exactly to prevent any cryptanalysis, making brute-force as last resort. Also, I have no enough knowledge in cryptography enough to do complex analysis. > Having said that, there are a lot of people on the Internet (some even > on this newsgroup) doing this kind of thing with very cheap FPGAs. I am > sure the Xilinx/Altera/Lattice/Actel/Quicklogic/Ateml guys are more > than happy to point out that their latest FPGA is the best one on the > market. > But the question is, even if you could afford the 10,000 USD it would > cost, would you really need it? could you really handle that beast? I don't know yet..Article: 107028
I'm putting together a system that requires a USB host and a USB device interface (two separate interfaces). On the 'device' side I need USB 2.0 high speed operation, on the 'host' side I can live with full speed operation. Perusing OpenCores I see the USB 2.0 Function IP Core which seems like it should work for the device side. Some questions: - What UTMI PHYs have people used with this core and can say that they work. The parts listed in the OpenCores document are no longer available, but the document is also 4 years old. - Any uCLinux device drivers available to support all of this? - Any other good/bad things to say about this core? Also on OpenCores is a USB 1.1 Host and Device IP core which would work for my USB host interface. - What USB transceivers have people used and can say they work. The OpenCores document lists a Fairchild USB1T11A and a Philips ISP1105, both of which are still available. Anything good/bad to say about either of these parts? - Any uCLinux device drivers available to support all of this? - Any other recommendations for transeivers? For either interface, does anyone have any recommendations on other IP cores (do not have to be 'free' cores) that have been used and tested and have a uCLinux device driver available that should be considered? Thanks in advance Kevin JenningsArticle: 107029
Peter Alfke wrote: > First, you have to decide how much logic you need, i.e. how much money > you want to spend. Between $1k and $2k. > Then you have to look at the two leading manufacturers, which are -in > order of size and speed- Xilinx and Altera > >From Xilinx, I would recommend the appropriate size Virtex-4 LX part, > or -if you need lots of multipliers and/or accumulators- the > appropriate size Virtex-4 SX part. > > If you are after max speed, you hardly need a microprocessor, but both > companies offer a soft microprocessor, it's called MicroBlaze in > Xilinx. > > Good luck, sounds like a fun project. I'm not the pioneer :-) http://en.wikipedia.org/wiki/EFF_DES_crackerArticle: 107030
John_H wrote: > Do you intend the brute force method to use many, many parallel units? It will be cool to use as many parallel units as they will fit in single FPGA chip. > How much do you want to spend? Between $1k and $2k.Article: 107031
Josh Model wrote: > >(cracking > >2E112 brute force is now considered "too easy"?) > > Woah. Is that really the case? These "farms" must be enormous-- if you > have 2 million instances of your cracking units running at, say, 500 MHz > (both of which seem sortof optimistic to me), you're still "only" doing a > quadrillion attempts per second. That's still many, many orders of > magnitude off the search space in any reasonable amount of time. Obviously, > I'm not a crypto guy, but are these proposal's really for "brute force" > farms? I cannot do any cryptanalysis yet.. And I need to test about 2^48 values. In another words, I need counter, I need block taking counter value at input and generating hashed value at output, I need comparator to test if the result is correct and I need something to stop all this stuff and begin to yell :-)Article: 107032
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:4l3kepF477jU1@individual.net... > John_H schrieb: >> Polarity bits. They're just extra bits, actually, intended for polarity >> or ECC algorithms and doesn't implement any polarity function on the >> data. If you don't use polarity or ECC you have a 36-bit memory >> interface available if you want it. >> >> Really basic stuff. The data sheet has the values listed. > > Polarity? Don't you mean Parity? > > Regards > Falk I love to laugh at myself. Thanks!Article: 107033
hypermodest wrote: > > 2nd: how much time do you got? > > Let's say, one week.. Well, lets say you have a search space of 2**60. You create a hash block that tests one key every clock cycle. you clock your system at 200 MHZ, and you put 256 of these blocks in the same FPGA: 2**60 / (200 000 000 * 256 * 3600 * 24 * 7) ~= 37 weeks (*) but for 2**48 you wil need only 1.5 hours. Of course, if you are totally new to FPGAs, there is no chance in hell that you can design a cracker so powerful in a week either. > > > 3rd: budget? I assume you are not working for NSA or similar YAT (Yet > > Another TLA) > > Between $1k and $2k. I know people do this for $99 (Xilinx S3 start kit). And I know people do it even better for $300-500 (some Terasic Altera kit). I think some major security chip was cracked using the former kit. But dont expect to break AES, 3DES or even vanilla DES with that kind of hardware. > > > 4th: do you really have the ambition to learn FPGA development for a > > simple homework? > > Yes, FPGA is really interesting area for me. Me too. I could do [and too often do] things like this just to learn new stuff. But are you here to learn or to solve a problem? > You're probably right. But good and modern crypto hash-functions are > designed exactly to prevent any cryptanalysis, making brute-force as > last resort. Also, I have no enough knowledge in cryptography enough to > do complex analysis. The hash function you presented in sci.crypt looks anything but modern. I wouldnt even use it to hash strings into a hash-table :) > I don't know yet.. If you just want to learn, get a simple starter kit from Xilinx or Altera. But dont expect to master them in a month or so. The stratix kit is overkill for you (and most of us for that matter). And while we are at it, AES128 is still safe. I bet the X-men will disagree, but mostly for marketing reasons :) burns * I have a feeling i did something wrong, these calculation use to end up with answers around millions of years or so :(Article: 107034
burn....@gmail.com wrote: > > > 4th: do you really have the ambition to learn FPGA development for a > > > simple homework? > > > > Yes, FPGA is really interesting area for me. > > Me too. I could do [and too often do] things like this just to learn > new stuff. > > But are you here to learn or to solve a problem? I'm here to learn by solving problems :-) > > You're probably right. But good and modern crypto hash-functions are > > designed exactly to prevent any cryptanalysis, making brute-force as > > last resort. Also, I have no enough knowledge in cryptography enough to > > do complex analysis. > > The hash function you presented in sci.crypt looks anything but modern. > I wouldnt even use it to hash strings into a hash-table :) Anyhow, no one answering me there. "+" operation in one place is making vacuum in my idea-generating part of mind. > > I don't know yet.. > > If you just want to learn, get a simple starter kit from Xilinx or > Altera. But dont expect to master them in a month or so. The stratix > kit is overkill for you (and most of us for that matter). That's why I'm here, to decide what to take.Article: 107035
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag news:44ECAD15.6030301@xilinx.com... > Antti wrote: >> >> Is that all the info about Virtex-5 board availability? My guess is >> that this time the best board (best price-performance) and first board >> available will be from Xilinx, so I will not go running to buy some 3rd >> party board before ML501 availability is known - but WHEN !? > > We have hundreds of these going through production builds right now and > they will be available for sale in September. > > Ed McGettigan > -- > Xilinx Inc. Thanks for update! looks like nice board :) AnttiArticle: 107036
"KJ" <Kevin.Jennings@Unisys.com> schrieb im Newsbeitrag news:1156363735.570149.227300@i42g2000cwa.googlegroups.com... > I'm putting together a system that requires a USB host and a USB device > interface (two separate interfaces). On the 'device' side I need USB > 2.0 high speed operation, on the 'host' side I can live with full speed > operation. > > Perusing OpenCores I see the USB 2.0 Function IP Core which seems like > it should work for the device side. Some questions: dont count on that. the core is used as basis for commercial core, yes. but the OpenCores version is not able to pass compliance testing IMHO > - What UTMI PHYs have people used with this core and can say that they > work. The parts listed in the OpenCores document are no longer > available, but the document is also 4 years old. > - Any uCLinux device drivers available to support all of this? > - Any other good/bad things to say about this core? > > Also on OpenCores is a USB 1.1 Host and Device IP core which would work > for my USB host interface. > - What USB transceivers have people used and can say they work. The > OpenCores document lists a Fairchild USB1T11A and a Philips ISP1105, > both of which are still available. Anything good/bad to say about > either of these parts? > - Any uCLinux device drivers available to support all of this? OC FS host-dev core has uClinux 2.6 drivers for NIOS-II > - Any other recommendations for transeivers? > doesnt really matter, most of them are useable actually. for HS ULPI is way better as it takes less wiring. > For either interface, does anyone have any recommendations on other IP > cores (do not have to be 'free' cores) that have been used and tested > and have a uCLinux device driver available that should be considered? > > Thanks in advance > > Kevin Jennings > for FPGA resource utilization the price for USB HS core is just way above dedicated silicon. eg adding a HS host-device chip to FPGA is cheaper than adding the PHYs an having an FPGA USB core. whatever FPGA USB IP core you choose, you end up spending 3 to 12 months with verification and compliance testing. AnttiArticle: 107037
Hello. By the way, does anybody here have enough sense of humor to build esoteric hardware using FPGA? Esoteric hardware can be extension of esoteric programming languages: http://en.wikipedia.org/wiki/Esoteric_programming_language There're also you may find brilliants like that: http://en.wikipedia.org/wiki/Malbolge_programming_languageArticle: 107038
burn.sir@gmail.com wrote: > burn.sir@gmail.com wrote: > > contsains "only" 2**64 keys, yes it can be cracked... but I am pretty > > sorry, make that 2**60. Of course, a professional cryptographer could > get that down to 2**10 or so in matter of minutes Again, I have no idea how to do this, but having hope though. > Speaking of those shady types, I happen to know a really good one. I > can ask him for help in exchange for that EP2S60 board ;) Huh, no thanks. > (kidding, kidding. besides, who wants a FPGA that is not supported in > the QII webpack?) What is QII webpack?Article: 107039
Frank Buss wrote: > PeteS wrote: > > > Do you want a processor you can simply instantiate, or are you willing > > to tweak so you get the features you want? If so, you could take one of > > the less ambitious cores and adjust the instruction set to optimise it > > for your application. > > Adjusting the instruction set to the problem domain is a good idea. I'll > try to write the functions, first, maybe using domain specific instructions > (like a block copy command), and then I'll implement the core for it. > > -- > Frank Buss, fb@frank-buss.de > http://www.frank-buss.de, http://www.it4-systems.de I did exactly this in a previous job. Picoblaze was nice, but there were things it did not have, and conversely things I would never use. So I did the code (pseudocode first) and then designed the device to do the necessary functions at the microcode level. Because my problem domain was very constrained, I needed only 16 instructions (I like it when I get nice numbers like that as a solution) to do what I needed. Then I wrote (well, I changed :) an assembler to program it. Worked very well, and took about half the space of a picoblaze, including a DMAC engine (excluding the memory interface which was there anyway). Cheers PeteSArticle: 107040
fpgakid@gmail.com wrote: > Hi All, > > I've released the first version of my Xilinx JTAG programmer for > Win32/Linux. I've got a spartan3e starter board, it connects to the PC through a USB cable. The windows software works fine, but under linux the only way I can get xilinx impact to download is if I first boot up in windows, then reboot into linux. Would your driver/software work with the spartan3e board with integrated USB device port? -DaveArticle: 107041
hypermodest wrote: > By the way, does anybody here have enough sense of humor to build > esoteric hardware using FPGA? I don't know what you mean, maybe some useless hardware projects for fun? What about building a Theremin: http://en.wikipedia.org/wiki/Theremin http://www.youtube.com/watch?v=eNl8qq-f1F0 I think with a FPGA it should be possible to produce much more interesting effects. Or plug-in a MIDI keyboard and implement a synthesizer, which simulates instruments physically correct. Output could be simply PWM (a FPGA is fast enough for a high output resolution) with an RC filter. http://www.fpga4fun.com/PWM_DAC.html -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 107042
Hi David, David wrote: > i am looking for any step by step guide to use uclinux on the starter > kit. A Linux-ready reference design for the Spartan3E500 starter kit is available now from PetaLogix: http://www.petalogix.com/news_events/Spartan3E500-ref-design Regards, John -- Dr John Williams www.PetaLogix.com (p) +61 7 33652185 (f) +61 7 33654999 PetaLogix is a trading name of UniQuest Pty LtdArticle: 107043
"Andy" <jonesandy@comcast.net> wrote in message news:1156356933.496598.141050@h48g2000cwc.googlegroups.com... > multi-cycle or false paths. > > So, if you have multi-cycle or false path constraints, and you're not > absolutely sure you have them properly applied so that they cover the > paths you intended, and not any paths you did not intend (usually the > culprit), then I would recommend a full-timing simulation, but focus on > the functions related to those constraints. > Right. It all relies on having the correct static constraints to start with. My own personal methodology for multi-cycle constraints is to code the RTL to make the constraints easy. (Ahem!) So, I use a signal as a global clock enable for the multi-cycle machine, and is _only_ used as a clock enable. Thus any path that is between elements driven by that enable is a multi-cycle path. It's nice and easy to specify these paths in a UCF file. > > There are a few formal tools supposedly coming out that can formally > verify, or even identify, multi-cycle and false path constraints for > you, but I don't have any experience with them. > > Andy > > That could be very useful. I guess there's a lot of designs, my own included, that have multi-cycle paths that aren't constrained as such because they meet the timing anyway. Perhaps PAR times could be reduced significantly if a tool could pick out these paths. Cheers, Syms.Article: 107044
This version supports only Digilent USB programmer cable! Unfortunately I don't have money to buy a Spartan-3E Starter Kit and reverse engineer the USB protocoll. ZoltanArticle: 107045
Hi, In opencores DDR implementation, the author uses a PLL to generate a clock of multiple phases. The PLL outputs true and inverted signals, in perfect sync. However the author doesn't use the inverting output of the PLL -- to generate an inverted output he inverts the true clock output and uses that. I'm trying to figure out why he did this. Is it because if you use the single clock source, then you only need one global clock buffer -- but if you use both, presumably there would be 2 global clock buffers used, and this is excessive for the design? Moreover the design needs a 2 phased clock. All clocks are 100 mhz. So 2 phases, 2 types (true/inverted) with minimum clock skew would necessitate 4 global clock buffers, right? Instead evidently he opted for just the 2 true clocks, then uses inverters when he wants the inverted version. Now this means the inverted signal will be delayed by the inverter. This appears on the order of .5 to 1 ns in the parts I'm interested in. So perhaps it's a tradeoff -- minimum skew requires 4 global clock buffers. Perhaps the inverter approach conserves global clock buffers at the expense of a little bit of skew. Anyway I just am looking for a sanity check. Does the reasoning above sound...reasonable? When designing is it necessary to keep these things in mind? Thanks-- DaveArticle: 107046
I appreciate the feedback guys. Sorry for the delayed response--I've been tied up all day. The interface, though it looks like Camera Link, is not. The V2PRO part would need to receive from three separate IC's ,each generating its own 45MHz clock and three lanes of x7 serialized data. So, yes, the FPGA would need to take the 45MHz and derive the 315MHz fast clock to pick off the data. So, based on this thread, there's nothing inherent about the DCM which would preclude it from this task. I wonder why this other group is telling me that the V2PRO can't do the job? Perhaps the V2PRO30 doesn't have enough DCM's? I believe the FPGA would need to have three, since there are three IC's generating the data. You couldn't just use one of the three clocks for all the data lanes because the three chips could have some slight variation in timing. The implemenation I chose was to use three PLL's, and clock everything into a FIFO to switch and sycnchronize all the data from the three chips into a single clock domain. I implemented this within a Stratix (sorry Austin--nothing personal. When I entered into the FPGA world my group used Altera) and it works. The design must be transferred to another group for a different design and the constraint (long story) is to use the V2PRO. The contingency plan is to use National's 90C flavor chips to deserialize the data before the V2PRO, thus sending it parallel data. My original post--due to my ignorance about the device--was to inquire about the DCM and its capability and limitations (if any) with this interface. Take care, Rob "Antti Lukats" <antti@openchip.org> wrote in message news:eci8hd$ml$1@online.de... > > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:echs1s$anl6@xco-news.xilinx.com... >> Oops, >> >> You still need to have the X7 clock, the the ISERDES does all the work. >> >> Austin >> >> Austin Lesea wrote: >>> Antti, >>> >>> Thank you. Yes, it does look like this is a X7 deserializer. In which >>> case the cheapest, fastest and easiest may be to just buy the ASSP that >>> was designed to do that job. >>> >>> I still think that V4 could also do this without any need for the ASSP >>> as the SSIO features include X7 sampling, without having to mutliply the >>> clock. >>> >>> http://direct.xilinx.com/bvdocs/userguides/ug070.pdf >>> page 355 >>> >>> Austin > > ah yes, the x7 must be there ;) > > well the OP asked for V2Pro - it is doable in V2Pro too. > V4 is maybe better withe ILOGIC > > but dedicated chip may even be better as it does the > job it was made to do. > > Antti >Article: 107047
PeteS wrote: > Frank Buss wrote: > > PeteS wrote: > > > > > Do you want a processor you can simply instantiate, or are you willing > > > to tweak so you get the features you want? If so, you could take one of > > > the less ambitious cores and adjust the instruction set to optimise it > > > for your application. > > > > Adjusting the instruction set to the problem domain is a good idea. I'll > > try to write the functions, first, maybe using domain specific instructions > > (like a block copy command), and then I'll implement the core for it. > > > > -- > > Frank Buss, fb@frank-buss.de > > http://www.frank-buss.de, http://www.it4-systems.de > > I did exactly this in a previous job. Picoblaze was nice, but there > were things it did not have, and conversely things I would never use. > > So I did the code (pseudocode first) and then designed the device to do > the necessary functions at the microcode level. Because my problem > domain was very constrained, I needed only 16 instructions (I like it > when I get nice numbers like that as a solution) to do what I needed. > > Then I wrote (well, I changed :) an assembler to program it. > > Worked very well, and took about half the space of a picoblaze, > including a DMAC engine (excluding the memory interface which was there > anyway). > > Cheers > > PeteS AHDL for a two register NOP, INC, DEC, WRITE unit http://indi.joox.net link to quartus II files, BIREGU.bdf good for interruptable stack pointersArticle: 107048
It looks pretty straightforward to me. Three incoming ~45 MHz clocks, each multiplied by 7 in its own DCM, triggering the input DDR registers. You have to do a little bit of thinking, because 7 is an odd number, but I see no problem with that. Of course, it would be much simpler in Virtex-4, but that seems to be not your choice. Peter Alfke, Xilinx (from home)Article: 107049
David Ashley wrote: [...] > However the author doesn't use the inverting output of > the PLL -- to generate an inverted output he inverts the > true clock output and uses that. >[...] > Moreover the design needs a 2 phased clock. All clocks > are 100 mhz. So 2 phases, 2 types (true/inverted) with > minimum clock skew would necessitate 4 global clock > buffers, right? Yep. > Instead evidently he opted for just the 2 true clocks, > then uses inverters when he wants the inverted version. > > Now this means the inverted signal will be delayed by > the inverter. This appears on the order of .5 to 1 ns in > the parts I'm interested in. Could you name the parts you are referring to? I find it surprising that an inverter within the global clock network would take that long, and more surprising that you can get off the global clock net and through a LUT-based inverter. So surprised, in fact, that I had to go try it for myself. I put three different examples in the design, rising_edge(clk), falling_edge(clk) as well as a clk_inv <= NOT clk were each clocking an output. The design used one global clocks and the inverter immedately in front of the FF (which doesn't take 0.5 ns). Synthesis tool (Synplicity) choice or tool options may have something to do with this. Of course, it pulled the FF for the outputs with inverted clocks out of the IOBs, but that's a separate issue > So perhaps it's a tradeoff -- minimum skew requires > 4 global clock buffers. Perhaps the inverter approach > conserves global clock buffers at the expense of a little > bit of skew. Don't forget the skew between different global clock nets caused by uneven loading of the clocks (if some have much heavier loading than others). > Anyway I just am looking for a sanity check. Does the > reasoning above sound...reasonable? When designing > is it necessary to keep these things in mind? Yes. These things, and many others :-) Have fun, Marc
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