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
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<abn893$r1u$1@newsreader.mailgate.org>... > > I believe if you don't specify whether or not you want the > hierarchy preserved by attaching a 'keep_hierarchy' synthesis attribute, > then XST will use the global keep hierarchy option instead. > The global keep hierarchy option is, of course, located under Synthesize > -> Properties -> Xilinx Specific Options or Synthesis Options. > If I want to add the keep hierarchy option to module_x and module_y, in > addition to module_b and module_c, here is how it will look. > > > ___________________________________________________________________________ > begin module_b > > attribute keep_hierarchy of module_b : entity is "yes"; > > end module_b; > > > begin module_c > > attribute keep_hierarchy of module_c : entity is "yes"; > > end module_c; > > > begin module_x > > attribute keep_hierarchy of module_x : entity is "yes"; > > end module_x; > > > begin module_y > > attribute keep_hierarchy of module_y : entity is "yes"; > > end module_y; > ___________________________________________________________________________ > > > > Just because module_x and module_y will be instantiated by module_b, you > will still have to have a separate "begin ... end" statement for each > module, and they won't be nested within module_b. > So, to answer your second question of whether or not the syntax is the > same for the submodules (instantiated modules), I believe the answer is > yes. > Yup, that sure did it. I've checked with the output EDN file and only the modules with the keep_hierarchy attribute set to "yes" remained. But something weird happened. The device usage still remained the same. There were no improvements. I was hoping that by eliminating the hierarchy between the submodules, XST could do a better job of optimizing the logic and area. Any comment on this?Article: 43076
Hi > > You know, this is a big problem and it's been around for many years. > > It's a problem in any design where you need fast OE performance, > > ZBT SRAMS, fast SDRAMs, etc. I'm surprised Xilinx hasn't fixed this > > long ago, I've complained to the support hotline on two different > > projects. [...] I'm not sure I understood You have problems with FF in IOB? Maybe You should look at (Xilinx) OnLine documentation in section: Constraints (Keep Hierachy, IOB) and VHDL - using "generate" or "loop" Try furiaArticle: 43077
hi i am new to reconfigurable computing. i am thinking of implementing the java virtual machine using fpgas for my final year project. it shall be done on handel-c. i would like comments on its feasibility and its practicability, also if anyone has any material on the same i would be very obliged to be sent those. kirentanna@rediffmail.comArticle: 43078
> i am thinking of implementing the java virtual machine using fpgas for > my final year project. it shall be done on handel-c. > > i would like comments on its feasibility and its practicability, You should search the web for this first, there are lots of projects doing exactly this.. For instance have a look at http://www.jopdesign.com/download.html or at http://www.fpgacpu.org/usenet/javaproc.html where the issue is discussed from a more general point of view. You might also have a look at the Computer architecture book of Tannanbaum who describes an implementation of a restricted version of the JVM in detail. If you implement just the simple arithmetic JVM instructions this should be not much differnt from targeting any other instruction set. But if you try to implement also the complex JVM instructions e.g. 'invokevirtual' it can get rather complex. Doing all in hardware i.e. dynamic class loading etc. will be an overkill, so you will end up by writing a supporting runtime library. Regards, Chris -- Christian Plessl remove 'remove' from email-address when replyingArticle: 43079
Hi all, I have a problem meeting timing constraints when using a DCM on a Virtex II (XC2V6000 speed grade 4. I use ISE 4.2 and Synplicity 7.0). I am using the DCM to do frequency synthesis in order to multiply the input clk (40 MHz) by a factor ranging from 2 to 5. The idea is to feed the multiplied clk (clkfx) to one port of a Dual-Port BRAM. All signals of the DP BRAM on the clkfx side are mapped to FPGA pins (no logic levels in between). All other components use the 40 MHz global clk. To my understanding, this shouldn't have a big influence on the maximum global clock frequency the design can reach. However, as soon as I introduce the DCM, the timing constraints (40 MHz) are missed by more 50%, on a design happily running at 45+ MHz otherwise. I use the DCM with a feed-back from CLK0 and with the following parameters: attribute DFS_FREQUENCY_MODE of U_DCM : label is "LOW"; attribute DLL_FREQUENCY_MODE of U_DCM : label is "LOW"; attribute DUTY_CYCLE_CORRECTION of U_DCM : label is "FALSE"; attribute CLKFX_DIVIDE of U_DCM : label is "2"; attribute CLKFX_MULTIPLY of U_DCM : label is "5"; attribute STARTUP_WAIT of U_DCM : label is "FALSE"; attribute CLKIN_PERIOD of U_DCM : label is "25 ns"; attribute CLK_FEEDBACK of U_DCM : label is "1X";-- using CLK0 as feedback However, DRC does generate this laconic message: INFO:DesignRules:547 - Blockcheck: To achieve optimal frequency synthesis performance with the CLKFX and CLKFX180 outputs of the DCM comp ipaq_interface/clk_fx/U_DCM, consult the Virtex-II Interactive Data Sheet. No answer in the data sheet nor anywhere else on the web for me to find. So any hints, clues, illuminations from you fpga-wizards are welcome. Regards, TheoArticle: 43080
See Atmel, www.atmel.com. "Romans @mindspring.com>" <romans52<remove_this> schreef in bericht news:gW_C8.80$sI5.11075835@newssvr21.news.prodigy.com... > I'm trying to locate an EEPROM equivalent to the X17S100A (OTP used for the > Spartan2-100). Do you have any recommendations? > > TIA, > Yen > >Article: 43081
Paul Smith wrote: > > Thanks to Hal, Kevin, Stephen, and Steve for their very helpful replies. > I have a much better understanding of what's going on now and what to > do next. > > A couple more questions: > > Should the memcpy() routine for accessing pci memory space? We don't > seem to be able to get it to work on an x86 linux box. Depends whether your program runs in kernel or userspace. In kernel space, memcpy may work, but only on X86 and is not recommended. The recommended method is to use the readb/readw/readl macros for read. memcpy may be implemented as byte accesses. Can your hardware handle that? In userspace memcpy won't work directly on the PCI address. You'll have to mmap (see manual page) the address range and then you can use memcpy on the returned pointer (if your hardware copes with single bytes). Kind regards, IwoArticle: 43082
A few days ago a friend of mine and I were inspired to build a new computer architecture, with the intent of making it easy to split tasks between hardware and software and implement them on a scalable system. And it would all be Open Source. So far this is still in the very early planning stages... There will be an off-the-shelf microprocessor (like maybe a StrongArm) running a conventional OS (Linux probably) combined with one or more FPGAs. The FPGAs and processor would be connected together with a relatively slow bus, with faster interconnect between adjacent FPGAs. Each fpga would have extra peripherals attached, and optionally a bank of memory separate from the CPUs memory. There would be a new language for designing hardware and software systems. Something along the lines of Handel-C, but object oriented. The idea would be that an object would be a precompiled hardware macro, and when it is instantiated it is loaded into the FPGA at runtime and connected to an internal bus that allows objects to pass messages between each other. It would be something of a combination between Handel-C and Objective C. Since both hardware and software objects would need to instantiate hardware objects, the FPGAs would actually have to reconfigure themselves. The CPU could perhaps use the boundary scan port to configure a bootstrap circuit that would then allow partial reconfiguration through the CPU's bus or the FPGA's message-passing bus. Anyway... Obviously this would be a huge effort, but to even get started I would need open source tools for bitstream creation, routing, etc, since there would need to be embedded software and/or hardware to place the object macros and route the busses together. I have read the threads at http://www.opencollector.org/news/Bitstream on the subject. With projects like this in the realm of the possible, it's quite annoying that the bitstream format is so closely guarded. (especially since the design security issue is being addressed by encryption in the Virtex II family) In the mean time, I'll take a crack at reverse engineering the bitstream for the Xilinx Spartan II. (Since that's what I have on hand) I would appreciate any comments on the feasibility of this whole idea. I've puttered around with FPGAs for a while now, but I still can't claim any serious experience. --MicahArticle: 43083
Well, I finally got the ISA bus working, but it took tacking 4.7k ohm pull-up resistors outside the FPGA to pull the bus up to a full 5V to do it. However, that isn't the end of the story. This was all for a school project, one that will bleed over into summer work, and I discovered last week that, as if by magic, the bus now works even when I remove the pull-up resistors!!! Either we have the most variant wire-wrap wire in the world or the most variant FPGA in the world!! I have noticed something odd though. I cannot get it working using the LVTTL io buffers at all. It works fine with the PCI33_5 buffers, but LVTTL is a no go (even when I put the pull-up resistors back on the bus). This is a mystery to me since they seem practically the same. The reason I was wanting to use LVTTL was because when I do a 16-bit ISA implementation I'd like to be able to specify the 24mA drive current on the IOCS16 signal (since I've read that that signal requires at least 20mA of drive). The PCI33_5 doesn't allow you to specify slew rate or drive current, and in the table for the PCI33_5 standard, under the current spec it has a note saying "tested according to appropriate spec." This would be fine if I could find a spec sheet on PCI that mentioned current, which I can't. I was just wondering if I would have any current concerns using PCI33_5 instead of LVTTL specified with 24mA of drive for the IOCS16 signal? Would it be better to instantiate all of these buffers in my VHDL rather than specifying everything in the constratin (.ucf) file as I'm doing now? I wouldn't imagine there would be any difference, but one never knows. The reason I ask is when I synthesize and implement my code using Foundation the pad report says the ports use PCI33_5, but when I go into FPGA Express and look at the optimized schematic it shows OBUF_s_12 buffers no matter if I use LVTTL or PCI33_5. I'm attributing this to some kind of updating bug in FPGA Express though as the two implementations are behaving differently (since PCI33_5 works and LVTTL doesn't), and it seems maybe FPGA Express just isn't showing the buffers correctly or something. If anyone has any ideas about the weird behavior of the bus feel free to chime in on that too, as I'm about ready to chuck the whole thing across the lab at this point :) SeanArticle: 43084
It would be helpful to be more specific. Instead of "LVTTL does not work", say: the Voh level is too low, or Vol is too high or too early, or too late.... These circuits do not mysteriously work or don't work. They show symptoms. Peter Alfke Sean wrote: > Well, I finally got the ISA bus working, but it took tacking 4.7k ohm > pull-up resistors outside the FPGA to pull the bus up to a full 5V to > do it. However, that isn't the end of the story. This was all for a > school project, one that will bleed over into summer work, and I > discovered last week that, as if by magic, the bus now works even when > I remove the pull-up resistors!!! Either we have the most variant > wire-wrap wire in the world or the most variant FPGA in the world!! > > I have noticed something odd though. I cannot get it working using > the LVTTL io buffers at all. It works fine with the PCI33_5 buffers, > but LVTTL is a no go (even when I put the pull-up resistors back on > the bus). This is a mystery to me since they seem practically the > same. The reason I was wanting to use LVTTL was because when I do a > 16-bit ISA implementation I'd like to be able to specify the 24mA > drive current on the IOCS16 signal (since I've read that that signal > requires at least 20mA of drive). The PCI33_5 doesn't allow you to > specify slew rate or drive current, and in the table for the PCI33_5 > standard, under the current spec it has a note saying "tested > according to appropriate spec." This would be fine if I could find a > spec sheet on PCI that mentioned current, which I can't. I was just > wondering if I would have any current concerns using PCI33_5 instead > of LVTTL specified with 24mA of drive for the IOCS16 signal? > > Would it be better to instantiate all of these buffers in my VHDL > rather than specifying everything in the constratin (.ucf) file as I'm > doing now? I wouldn't imagine there would be any difference, but one > never knows. The reason I ask is when I synthesize and implement my > code using Foundation the pad report says the ports use PCI33_5, but > when I go into FPGA Express and look at the optimized schematic it > shows OBUF_s_12 buffers no matter if I use LVTTL or PCI33_5. I'm > attributing this to some kind of updating bug in FPGA Express though > as the two implementations are behaving differently (since PCI33_5 > works and LVTTL doesn't), and it seems maybe FPGA Express just isn't > showing the buffers correctly or something. > > If anyone has any ideas about the weird behavior of the bus feel free > to chime in on that too, as I'm about ready to chuck the whole thing > across the lab at this point :) > > SeanArticle: 43085
In article <abhekf$11kc$1@agate.berkeley.edu>, nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) wrote: >In article <TKVC8.106$Kg.116730@news.uswest.net>, >Alex Rast <arast@inficom.com> wrote: > >>First, a preliminary question. Several people have noted that the PCI >>cores from Xilinx and Altera are both hard macros, ... >>. But with the Xilinx version for example, can I still get >>in with FPGA Editor and edit it manually? This is what I'd expect to >>do anyway by way of tweaking - I think that the kinds of tweaks we >>might need to do to get the PCI cores to work right in our device >>would be at the hard-macro level anyway. So as long as I could do >>this, the fact that both vendors supply only hard macros wouldn't be >>a real obstacle. > >How much tweaking would you want/desire? I'm assuming that, since the >hard macros force the pins, the rest of the layout ends up being nice >and constrained along the interfaces. I didn't think the hard macros *force* the pins, in the sense that tools like FPGA editor wouldn't let you reassign the pins, by unrouting the macro connection and rerouting it to a different bonding pad. However, if you look inside the detailed low-level architecture, you find, with typical FPGA's, that the way the blocks are laid out on chip tend to force certain directions anyway, by the nature of what's convenient to route and place, so you usually end up with something pretty close to the original design anyway. What I would hope to be able to do with *any* IP core no matter what the provenance or application (i.e. PCI or any other large function) is to edit the block placement, routing channels, possibly pinout (less likely with PCI than with others) so as to be able to fit other things on board the chip most efficiently, or add functionality to the existing IP core. >... >> What we really >>care about is delivering maximum value to the customer - and >>customers expect products that work first time, every time, with a >>minimum of installation, that don't break down in a day, or a month, >>or a year, and that have high performance. .. >This directly issues the ASIC vs FPGA tradeoff, and the size of the >FPGA you would use. > >Small FPGAs (eg, Spartan II 300) are relatively cheap and have some >other nice properties (namely, low inventory costs), so that, combined >with the lower NRE cost, end up being quite nice, until you start >talking considerable volume of ASICs > >Large FPGAs, on the other hand, are HIDEOUSLY expensive, so may not be >that useful outside the small quantity, high markup section of the >market. What would concern us most about large FPGA's is, given their high prices, are the chip fabs able to produce them in high volume? (High prices would tend to suggest that the answer to this question is no). For a high-value application, for instance, the high price wouldn't necessarily be an issue, but even a 50-cent part isn't going to do you any good if you can't get enough chips to meet demand. The smaller FPGA's arouse less concern about volume given that the lower price suggests bulk availability, and for many apps where ultra-complex functionality weren't necessary, would be the obvious solution. >>Are you concerned about the possibility that someone will intercept the >>configuration bitstream and steal our IP? I don't think this is something you >>can prevent (at least, prevent people from trying) if you've got a hot >>technology. > >Virtex II can (but is pricey, and I'm not sure what glue you need >outside to do 5V PCI), or at least make the obstacle pretty damn high >(extracting the value of SRAM cells). You think their encryption is going to stop a determined opponent? NOT! If you have a good product and a clonemaker who really wants to gain market entry (i.e. the market is big enough), there'll be someone smart enough, persistent enough, or exhaustive enough to do it. In the limit, they'll just buy a bunch of FPGA's from the manufacturer (say 1000), integrate them into a big box, and brute-force it out. It's not worth trying to go to any special trouble to stop. We'll just do what a "reasonable company" might do and stop there. .. > >>>- Play devils advocate. What if somebody like me saw your product and wanted >>>to copy it?... > >>As I said, I don't think this is something you can or should try to >>prevent. ... From our perspective the most important thing to do is >>design a product which has the most room for enhancement as new >>silicon and technologies become available... >Or patent things enough and sic the lawyers on them. Nah. Of course you patent, but with the understanding that it's basically worth the paper it's printed on. Attorneys rarely solve anything. Big companies will simply drag on the case in court long enough to outlast you financially in terms of the fees they can shell out. Small companies can sue for nuisance value, and each lawsuit diverts energy which could have been put into product development or customer service, which weakens you as a company. Besides, once somebody else has a product out in the market, it doesn't matter. Most clones will take the position "we'll just build it and ship it. Let *them* sue if they want to. It'll take years for them to get a judgement, by which time we'll have market penetration anyway." So why fight in the courtroom and try to get a legal solution to a business problem? Compete in the marketplace instead, and indeed let them have their position (commodity, usually) while you have yours (technology and reliability, typically). There's room for both without fighting. Everybody wins. > >>>- What are you views on IP protection? If I see a PCB with a configuration >>>EPROM I see something that can be copied and pushed on the grey market. > >>You've seen it all above. If they want to duplicate the hardware >>slavishly, they probably can. If they want to intercept the >>configuration bitstream, they probably can. > >I don't think large scale gray market cloning should be TOO much of a >problem: with good inventory control and distribution on your side, >bogus product should be fairly recogniseable: Simply serial number >everything, both the boards AND the configurations, and you should be >able to track the leaks of configuration and cloners. > We might do that to provide better customer service (a customer always likes it when you can identify to him what product and configuration he's got, without him having to look it up or determine it for himself, especially when he might not know exactly what information you're looking for), and what IP protection we got as a result would be a side benefit. The one thing we'd have to be careful about is to make sure that a corporate policy and philosophy is in place where customer service isn't going to get rigid about serial numbers, exploiting every opportunity they can to claim customer X isn't entitled to customer service on the basis of serial number or lack thereof. Unless we had *positive* proof that the user in question was using a unit that in every way was a clone product, I think we'd want to be inclined to provide customer support. And the support effort should *never* focus on obtaining such "positive" proof. >>*Real* investors (such as we have) have 2 main traits: First, they're >>prepared to wait many years (at least 10) for a technology in its >>infancy to mature and grow their initial investment into a solid >>company. Second, they're prepared to contribute in ways other than >>financial to help you succeed - and this doesn't mean simply sending >>in the MBA's. It means making some sort of personal contribution in >>whatever way thay can. These kind of investors don't pester you with >>constant "how soon?" questions. Rather, they ask, "how can I help?" > >Where do you find these investors? I could use a few. If you have the right company philosophy, those kinds of investors follow as a matter of course. > >>What I hate is that the documentation for all FPGA's is invariably >>incomplete,.... Even more irksome is the vast gulf between the S/W tools and >>the hardware capabilities of the device. > >For the tool point: they have in the past, and you could do that now >(XDL allows PIP level manipulation, so does Jbits, just in programatic >ways), but it is actually pretty useful: The routing fabrics are so >rich and so fast that, within a very small epsion, an automated tools >is as good as the best human designer. *NOT EVEN CLOSE!!!!* I did a few test programs on a couple of complex, dense modern FPGA's, comparing my own hand-configured, placed and routed version against one built using the full tool design flow, and in every case wiped them off the map in terms of routing efficiency, density, utilization, speed, and indeed even functionality (with several of the designs the automated tools produced results that wouldn't perform the functionality they were supposed to.) It was laughable, exactly as I expected. Alex Rast arast@qwest.net arast@inficom.comArticle: 43086
micahjd@users.sourceforge.net (Micah Dowty) writes: > Since both hardware and software objects would need to instantiate > hardware objects, the FPGAs would actually have to reconfigure > themselves. More likely be reconfigured by external stuff, i.e. your CPU. > The CPU could perhaps use the boundary scan port to > configure a bootstrap circuit Or for lot faster reconfig use the SelectMap interface. It costs IO pins, but for your data processing style application pin count should not be limiting. > Anyway... Obviously this would be a huge effort, but to even get > started I would need open source tools for bitstream creation, > routing, etc, The old problem. Appears in a thread about every 1/4 to 1/3 of a year. :-) > on the subject. With projects like this in the realm of the possible, > it's quite annoying that the bitstream format is so closely guarded. Nitpick: not "closely guarded", just "not published". According to Peter Alfke of Xilinx it is not about secrecy, but more that they do not want the support costs from people trying to roll their own tools. Published = must be supported in the commercial world. That open source programmers accept non-supported stuff is a new thing in FPGA development circles. They have still got to get used to our different culture. Give them a bit of time and they will digest it. > (especially since the design security issue is being addressed by > encryption in the Virtex II family) The info on Virtex (and so also Sparten-II) bitstreams is acually out here, just not in an user friendly form. Xilinx is actually an exeption in this respect, all other vendors do not publish such info at all. Try the following stuff: Virtex datasheet http://www.xilinx.com/partinfo/ds003.pdf (the basics how the chip works, Spartan-II is the same) + XAPP138 Virtex Configuration and Readback http://www.xilinx.com/xapp/xapp138.pdf (how to load the chip, important for your reconfiguring, btw) + XAPP151 Virtex Series Configuration Architecture User Guide http://www.xilinx.com/xapp/xapp151.pdf (how the bitstream is formatted, LUT/FF/IOB/BRAM data bit positions) + JBits config API, an set of Java .class files to modify bitstreams mailto:jbits@xilinx.com (its docs document what bits exist in the stream, how routing looks) (JBits may actually be all that you need, not the bitstream, if you write your compiler in Java!) + use JBits to experimentally determine bit positions (make various configs and look where the bits appear) > In the mean time, I'll take a crack at reverse engineering the > bitstream for the Xilinx Spartan II. (Since that's what I have on > hand) Looking at how long your project will take (just defining your language and how to split it CPU/FPGA), I will most likely have that already finished before you get around to doing it. It has been on my project list for about 1 year, and now that my job change is through, I can start off doing it. http://neil.franklin.ch/Projects/VirtexTools/ > I would appreciate any comments on the feasibility of this whole idea. Possible, just a lot of work. Which is why I needed the new half-time job first. :-) > I've puttered around with FPGAs for a while now, but I still can't > claim any serious experience. In my case an partially done FPGA-CPU project, using JBits: http://neil.franklin.ch/Projects/PDP-10/ -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Make your code truely free: put it into the public domainArticle: 43087
Theo, It looks OK to me. The jitter from the CLKFX pin will be between 710 ps P-P and 860 ps P-P for all combinations of M and D from M=2, D=1, to M=5, D=4. This is what the interactive note is pointing you to, the jitter calculator tool, which isn't out yet, but is available by opening a case, or posting here for the answer, or by contacting your FAE. Have you taken the worst case ~ 430 ps less slack (half of the P-P) into account in your timing constraints? Also there are some updates for the BRAM in the latest speeds files, so you may want to look for that as well. Austin Theo wrote: > Hi all, > > I have a problem meeting timing constraints when using a DCM on a > Virtex II (XC2V6000 speed grade 4. I use ISE 4.2 and Synplicity 7.0). > I am using the DCM to do frequency synthesis in order to multiply the > input clk (40 MHz) by a factor ranging from 2 to 5. > > The idea is to feed the multiplied clk (clkfx) to one port of a > Dual-Port BRAM. All signals of the DP BRAM on the clkfx side are > mapped to FPGA pins (no logic levels in between). All other components > use the 40 MHz global clk. > > To my understanding, this shouldn't have a big influence on the > maximum global clock frequency the design can reach. However, as soon > as I introduce the DCM, the timing constraints (40 MHz) are missed by > more 50%, on a design happily running at 45+ MHz otherwise. > > I use the DCM with a feed-back from CLK0 and with the following > parameters: > attribute DFS_FREQUENCY_MODE of U_DCM : label is "LOW"; > attribute DLL_FREQUENCY_MODE of U_DCM : label is "LOW"; > attribute DUTY_CYCLE_CORRECTION of U_DCM : label is "FALSE"; > attribute CLKFX_DIVIDE of U_DCM : label is "2"; > attribute CLKFX_MULTIPLY of U_DCM : label is "5"; > attribute STARTUP_WAIT of U_DCM : label is "FALSE"; > attribute CLKIN_PERIOD of U_DCM : label is "25 ns"; > attribute CLK_FEEDBACK of U_DCM : label is "1X";-- using CLK0 > as feedback > > However, DRC does generate this laconic message: > INFO:DesignRules:547 - Blockcheck: To achieve optimal frequency > synthesis > performance with the CLKFX and CLKFX180 outputs of the DCM comp > ipaq_interface/clk_fx/U_DCM, consult the Virtex-II Interactive Data > Sheet. > > No answer in the data sheet nor anywhere else on the web for me to > find. So any hints, clues, illuminations from you fpga-wizards are > welcome. > > Regards, > TheoArticle: 43088
Micah Dowty wrote: > > A few days ago a friend of mine and I were inspired to build a new > computer architecture, with the intent of making it easy to split > tasks between hardware and software and implement them on a scalable > system. And it would all be Open Source. > > So far this is still in the very early planning stages... There will > be an off-the-shelf microprocessor (like maybe a StrongArm) running a > conventional OS (Linux probably) combined with one or more FPGAs. The > FPGAs and processor would be connected together with a relatively slow > bus, with faster interconnect between adjacent FPGAs. Each fpga would > have extra peripherals attached, and optionally a bank of memory > separate from the CPUs memory. > > There would be a new language for designing hardware and software > systems. Something along the lines of Handel-C, but object oriented. > The idea would be that an object would be a precompiled hardware > macro, and when it is instantiated it is loaded into the FPGA at > runtime and connected to an internal bus that allows objects to pass > messages between each other. It would be something of a combination > between Handel-C and Objective C. > > Since both hardware and software objects would need to instantiate > hardware objects, the FPGAs would actually have to reconfigure > themselves. The CPU could perhaps use the boundary scan port to > configure a bootstrap circuit that would then allow partial > reconfiguration through the CPU's bus or the FPGA's message-passing > bus. > > Anyway... Obviously this would be a huge effort, but to even get > started I would need open source tools for bitstream creation, > routing, etc, since there would need to be embedded software and/or > hardware to place the object macros and route the busses together. > > I have read the threads at http://www.opencollector.org/news/Bitstream > on the subject. With projects like this in the realm of the possible, > it's quite annoying that the bitstream format is so closely guarded. > (especially since the design security issue is being addressed by > encryption in the Virtex II family) > In the mean time, I'll take a crack at reverse engineering the > bitstream for the Xilinx Spartan II. (Since that's what I have on > hand) > > I would appreciate any comments on the feasibility of this whole idea. > I've puttered around with FPGAs for a while now, but I still can't > claim any serious experience. Getting in at the bitstream level is not a great idea, for the first stages. Better to learn up on the existing file-level entry choices, from EDIF up to VHDL/Verilog, as well as the soft cores about. As for a top-level language, C is far from ideal, as it always quickly morphs into 'a new language', and looses any benefit. What is needed is a parallel language, that can run on PCs or FPGAs, with common source. You then get fpga-simulation for free, and do NOT have to make early-parition decisions, plus can easily deploy on multiple cores. See my earlier post (pasted here) : ASML is working now on PCs. Jim Granville Wrote: > I also came across this recently, > > http://www.research.microsoft.com/fse/asml/ > > and it seemed to me, this could have FPGA applications. > > A key weakness of C, is the sequential nature of all descriptions, > and the fact that FPGA "C's" are not C at all, but are some > 'variant of the C programming language' - they seem more keen > on getting the magic buzzword C in there, than in how it can be used > practically. Throwing thousands of HW novice C coders at FPGAs sounds > more a problem than a solution :-) > > ASML is inherently parallel, until 'step' in invoked, and thus > the SAME source could potentially target an OpCode or FPGA at runtime. > > This from the overview > > It is only after a step has been made that the new values > > become visible. > > In general, a computation in AsmL is not sequential unless > > explicitly marked as being so. > > ASML would encourage 'sea of CPU' innovations on the PC, as well as > FPGA implementations. > Because it has a path to compile -> Runs on a PC, that also gives a > Simulation path, to verify the logic on FPGA. The best 'horizon' approach would be - A language that is inherently parallel and capable of HW description (More than one language support would be good : some problems suit some languages better than others). - A three way path for that language, to allow a) Run on a PC/ARM/PPC etc HW, ie Hard core with maximal resource b) Run on a soft-core, ie FPGA core with minimal resource c) Run in FPGA HW Some discussion on Java in FPGA's is already underway, another pathway would be to implement .NET MSIL in FPGA/Softcore combination. .NET is new, but already looks a more stable pivot point than Java flavours, and .NET has good language support already - See http://msdn.microsoft.com/vstudio/partners/language/default.asp This would lead to .NET core(s) in FPGA, with key code sections chosen as FPGA-Macros, running as a system. jgArticle: 43089
Jim Granville wrote: > > Micah Dowty wrote: > > > > A few days ago a friend of mine and I were inspired to build a new > > computer architecture, with the intent of making it easy to split > > tasks between hardware and software and implement them on a scalable > > system. And it would all be Open Source. > The best 'horizon' approach would be > > - A language that is inherently parallel and capable of HW description > (More than one language support would be good : some problems suit > some languages better than others). > > - A three way path for that language, to allow > a) Run on a PC/ARM/PPC etc HW, ie Hard core with maximal resource > b) Run on a soft-core, ie FPGA core with minimal resource > c) Run in FPGA HW This may be a stupid question, but would it be feasible to have native VHDL support on a microprocessor? Preferably compiled, but even interpreted would be a starting point. Imagine the flexibility of being able to do your entire design in VHDL, then choosing, perhaps on the fly, which parts are instantiated in hardware and which in software... Regards, JohnArticle: 43090
> > A key weakness of C, is the sequential nature of all descriptions, This is not really correct. C has lots of parallelism. It always amazes me when people say there is no parallelism. Here is a line of very parallel C code. a = b+c, d= e+f, Myfunc(); According to the C specs the above line can be executed in parallel. The problem is if you can get different answers since the specs don't say what order they must executed in if you do them one at a time. example a = b , b = a ; Could be "a" and "b" have the value of "a" or they have the value of "b" or "a" and "b" swap values. It's one of the reasons Java only has lists for initializations. If you write a compiler you'll see what I mean. SteveArticle: 43091
Hi Michael, Micah Dowty wrote: > > > Anyway... Obviously this would be a huge effort, but to even get > started I would need open source tools for bitstream creation, > routing, etc, since there would need to be embedded software and/or > hardware to place the object macros and route the busses together. > > I have read the threads at http://www.opencollector.org/news/Bitstream > on the subject. With projects like this in the realm of the possible, > it's quite annoying that the bitstream format is so closely guarded. > (especially since the design security issue is being addressed by > encryption in the Virtex II family) > In the mean time, I'll take a crack at reverse engineering the > bitstream for the Xilinx Spartan II. (Since that's what I have on > hand) > I too recently read those threads at opencollector.org... interesting stuff. Recently I've been researching the XC4000 series readback functionality, and in the process of debugging it I've learned some very interesting things about the bitstream format. In particular, we found a simple method that could, in principle, be used to reverse engineer the bitstream. Or more precisely, reverse engineer the relationship between a placed and routed design, and the corresponding bitstream. The idea of actually developing a tool to do the constrained routing etc just makes my head hurt. As other correspondents have said, the bitstream is not so much "secret", as unpublished. Although that said, I'm not sure how Xilinx would react should someone post on a website a clearly written document outlining the details with accompanying code. Comments anyone? Anyway let me know if you are really interested to hear more about the bitstream stuff. I tend to agree with one of the other posters, who said (more or less) that you'd be better starting off at a higher level and working down. Otherwise you're likely to get bogged down in the interesting, but time-consuming task of figuring out the bitstream, rather than your grand system ideas (which sound v. interesting by the way - do a search for hardware software codesign) Regards, JohnArticle: 43092
John Williams wrote: > > > As other correspondents have said, the bitstream is not so much > "secret", as unpublished. Although that said, I'm not sure how Xilinx > would react should someone post on a website a clearly written document > outlining the details with accompanying code. Comments anyone? Speaking for myself ( I am not the official Xilinx spokesman, even if I behave like that occasionally): I am concerned about a publicized bitstream decoder for two reasons: 1. It might make some users feel vulnerable that their design can be reverse-engineered and then slightly modified to hide the rip-off. 2. It might expose Xilinx to unreasonable and unsupportable user questions, especially when they painted themselves into a corner. And he who sells the chips ultimately is stuck with the cry for help... Peter AlfkeArticle: 43093
Hello, I am a Altera Nios user, and happen to have started a Developer Community. There is currently very little content on my site, but that's because I just finished setting it up. If you have any information about using the Altera Nios Softecore processor, and or Sopc_Builder that you'd like to share please feel free to post to my site. www.twistedminds.org/nios This is not an Altera associated Web Site. It's just something I put together late one night.Article: 43094
In article <3CE03B81.B6624D70@xilinx.com>, Peter Alfke <Peter.Alfke@xilinx.com> wrote: >Speaking for myself ( I am not the official Xilinx spokesman, even if I >behave like that occasionally): >I am concerned about a publicized bitstream decoder for two reasons: > >1. >It might make some users feel vulnerable that their design can be >reverse-engineered and then slightly modified to hide the rip-off. *cough* Jbits *cough*. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43095
Hi Peter, Peter Alfke wrote: > Speaking for myself ( I am not the official Xilinx spokesman, even if I > behave like that occasionally): I understand your position - I think your participation in this group is a great thing and I hope your employer actively supports it. > 1. > It might make some users feel vulnerable that their design can be > reverse-engineered and then slightly modified to hide the rip-off. Yes, however in the long run "security-by-obscurity" is not sustainable. I'm guessing you are probably moving towards (already there?) bitstream encryption that would help deflate this aspect somewhat? > 2. > It might expose Xilinx to unreasonable and unsupportable user questions, > especially when they painted themselves into a corner. And he who sells the > chips ultimately is stuck with the cry for help... Indeed. With a hacked bitstream it would probably be easier than not to cook a device. Having worked in support before I'm familiar with the fact that users will lie about what they've done because they know they did the wrong thing, are embarrassed, but still want the help. "No, we didn't hack the bitstream, it came fresh from your tools!". How about a serial number generator in BITGEN, so when user has trouble you could ask for a copy of the .bit file, if it doesn't contain a valid serial then you say sorry, can't support you if you didn't use our tools. Of course, then someone could just hack the serial number generator, and so it goes... Regards, JohnArticle: 43096
In article <3CE0404E.AE4B37C5@qut.edu.au>, John Williams <j2.williams@qut.edu.au> wrote: >Yes, however in the long run "security-by-obscurity" is not sustainable. > >I'm guessing you are probably moving towards (already there?) bitstream >encryption that would help deflate this aspect somewhat? Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key is then loaded (through JTAG) into a distinct register on the part, which has a separate power pin to maintain state. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43097
John Williams wrote > This may be a stupid question, but would it be feasible to have native > VHDL support on a microprocessor? Preferably compiled, but even > interpreted would be a starting point. That is what the compiled simulators do. Performance is not great...Article: 43098
Nicholas Weaver wrote
> Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key
> is then loaded (through JTAG) into a distinct register on the part,
> which has a separate power pin to maintain state.
All together, for the umpteenth time:
"Please can we have these few register bits as flash"
Article: 43099Peter Alfke wrote: > > > These circuits do not mysteriously work or don't work. ... ... unless they're being eaten by the great metastability beast. Maybe the work/!work is related to seasonal variation in lab temperature :-).
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