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
Gabor wrote: > David Dye wrote: > > >>Gabor, >> >>Hiding specific messages is a feature that exists in XST 6.Xi and will >>be enhanced in 7.1i. This feature was added to reduce runtime as well >>as log file size and clutter. >> >>In the 6.Xi tools, use the XIL_XST_HIDEMESSAGES environment variable to >>filter all messages that fall into two categories. The set of messages >>filtered are fixed, but #382 is one of the low level messages. Consult >>chapter 9 of the XST User Guide for the lists of messages and details >>about how to enable this feature. The message filtering was implemented >>in this way to be a stepping stone for the functionality planned for 7.1i. > > > Thanks for the tip, this really reduces my build time! Good to hear. Glad to help. > >>In ISE 7.1i (due out in a few weeks), there is a message manager that >>will allow the user to filter out not only specific messages by number, >>but also specific instances of specific messages. This feature will >>extend filtering beyond just XST; most of the implementation tools will >>take advantage of this feature. >> > > > So does this mean I'll be able to "mark" warnings in a report file > viewer somehow so it doesn't appear on the next build? i.e. can > I effectively see only new messages on each successive build? What you'll see on subsequent runs depends on how you mark the existing messages. For example, if you say "Filter all instances of this message", then it will hide all messages with a particular number, even new ones. You can also say "Filter this instance only", and any new ones will show up. Of course if you have over 8000 instances, you won't want to set the individual filter for each one. We will have wildcard capabilites later this year. When 7.1i comes out check out the help pages on the message filter to learn about all the new capabilities. > > >>As for the messages in the first place, have you tried inferring these >>registers? XST will pack output and output enable flops in the IOBs, >>and will replicate the output enable flops if necessary. > > > I didn't try inferring the registers, because I took this part of the > design from a Xilinx reference design (XAPP 608) so I had this problem > from the beginning. Also in this case the warnings were not hard to > ignore because they were together in one long section of the report > file. > Really just the build time was the headache. > > >>thanks, >>David Dye >>Xilinx Technical Marketing thanks, David Dye Xilinx Technical MarketingArticle: 78776
Hi I am using JBITS to generate an anticore for a virtex device. When I run the MAP process I get the error, below. Could anyone give me some insight as to what exactly it means, or even better how I might fix it? Thanks -J "FATAL_ERROR:Ncd:basnccomp.c:3516:1.29 - Cannot find other bel for unconnected pin on bel <0>.WSGEN:CK of comp coreoutbus<0>. Its current programmed state is : YUSED:0 XUSED:0 F:#RAM:D=0x0000 G:#RAM:D=0x0000 RAMCONFIG:2SHIFTS SRMUX:1 GYMUX:G FXMUX:F Process will terminate. To resolve this error, please consult the Answers Database and other online resources at <http://support.xilinx.com>"Article: 78777
tesla wrote: > Hi, > > I will send 16 bit/pixel video data from PC to a FPGA board > through USB 2.0 interface. > I think Trenz electronic's Micromodule is suitable for this. It has a > USB physical interface ic GT3200. > > Has anybody used it for this kind of job? AFAIK the micromodule has only been used with Rudolf Usselmanns USB1.1 core so far. But there is no reason why the 2.0 core should not work on the board. We have not tried it yet because the interface to the 2.0 core is more complicated. Kolja SulimmaArticle: 78778
Glen, " > I do wonder if the optimal LUT size has changed over the years. > > Is there work showing the optimal LUT size as a function of silicon > resources needed to implement such LUTs?" Good point. Paul has referred to their studies of replacing a 4 LUT with a 6 LUT, and then re-running synthesis to see just how much improvement one sees. Assuming one can get enough >4 term, <=6 term logic synthesised, one saves logic levels, and improves speed (even if a 6 LUT is slower than a 4 LUT). Then comes the other nagging questions: - are inputs shared? - how badly does that mess up the results? - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra logic to almost give you a 6 LUT? How badly does that work? - given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, how badly does that increase the delay? I would claim a properly engineered 6 LUT would improve the overall performance. A compromise would provide some improvement. A poor implementation woukd make no difference. Should all LUTs be 6 LUTs? Or a mixture of both? In what ratio? Can you use them as SRL? LUT RAM? The synthesis tools all have to be retuned, and debugged to take advantage, so this is not without risk. As for area, a 6 LUT is not all that big as technology shrinks, so some combinations of variable LUT size, alternate architectures, is in my opinion, inevitable. As for speed, the smaller the technology, the less improvement in speed (ITRS roadmap, and anyone who says differently can be confidently ignored). For speed, one now has to use triple oxide to get both speed and static power reduction (eg compare us to S2 at 25C and there is no difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the static power!). The wonderful thing about standard CMOS, is just that. No one has a remarkably different or unique process. But one can use standard CMOS with all of the available tricks, and see a 1/2 to 1/3 reduction in static power, an improvement in speed, and an improvement in SEU resilience. Like V4. Also, there is room for improvement with the P&R tools, so software is always looking for that QOR improvement that gives us another speed grade advantage without any process change. So far they do that every generation (they get credit for part of the improvement in speed with each generation, too, including the most recent ones). AustinArticle: 78779
The Xilinx timing report for XPLA3 CPLD shows maximum operating frequency of 30 MHz for one of our design. But the CPLD is functioning correctly at 80 MHz. If so what does the Maximum operating frequency specified in the timing report signify?Article: 78780
Hi, I am quite new in FPGA, and want to ask something. I hope some of you can give me a hint of how to do. I have finished developed an application using the Celoxica RC100 Development Board, and Handel-C. Currently I am looking for a way on how to do the prototyping on other boards. I made all the application using the PAL (Platform Abstraction Layer), and I also use the Flash memory of the RC100 board. I am afraid that the Virtex II Prototype Platform AFX-FF1152-200/XC2V4000 Board that I am going to use, doesn't have any flash memory with it. I used flash memory to store the configuration bits, because I divided the application into several parts. And do FPGA Configuration in the later part. So, is there any expert out there who can suggest me on how to do it? Thanks, Johan.Article: 78781
Has anyone had any sucess in using RocketIO from Virtez 2 or Virtex 4 for Serial ATA applications? From the information collected on various news groups and web sites, my understanding is SATA OOB cannot be done using RocketIO in Virtex 2s. Did any one try Virtex 4s? What is the comment from FPGA gurus out there? - sgArticle: 78782
austin wrote: > Glen, > > " > I do wonder if the optimal LUT size has changed over the years. > >> >> Is there work showing the optimal LUT size as a function of silicon >> resources needed to implement such LUTs?" > > > Good point. Paul has referred to their studies of replacing a 4 LUT > with a 6 LUT, and then re-running synthesis to see just how much > improvement one sees. > > Assuming one can get enough >4 term, <=6 term logic synthesised, one > saves logic levels, and improves speed (even if a 6 LUT is slower than a > 4 LUT). > > Then comes the other nagging questions: > - are inputs shared? > - how badly does that mess up the results? > - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra > logic to almost give you a 6 LUT? How badly does that work? > - given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, > how badly does that increase the delay? > > I would claim a properly engineered 6 LUT would improve the overall > performance. A compromise would provide some improvement. A poor > implementation woukd make no difference. > > Should all LUTs be 6 LUTs? Or a mixture of both? In what ratio? > > Can you use them as SRL? LUT RAM? > > The synthesis tools all have to be retuned, and debugged to take > advantage, so this is not without risk. > > As for area, a 6 LUT is not all that big as technology shrinks, so some > combinations of variable LUT size, alternate architectures, is in my > opinion, inevitable. > > As for speed, the smaller the technology, the less improvement in speed > (ITRS roadmap, and anyone who says differently can be confidently > ignored). For speed, one now has to use triple oxide to get both speed > and static power reduction (eg compare us to S2 at 25C and there is no > difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the > static power!). > > The wonderful thing about standard CMOS, is just that. No one has a > remarkably different or unique process. But one can use standard CMOS > with all of the available tricks, and see a 1/2 to 1/3 reduction in > static power, an improvement in speed, and an improvement in SEU > resilience. Like V4. and Intel also varies the Vth over 21 steps, to have CLK, Vdd, Vth to tune for speed/power trade offs. http://www.eet.com/semi/news/showArticle.jhtml;jsessionid=TWZH2G3BR2K2OQSNDBCSKHSCJUMEKJVN?articleId=59301578 > > Also, there is room for improvement with the P&R tools, so software is > always looking for that QOR improvement that gives us another speed > grade advantage without any process change. So far they do that every > generation (they get credit for part of the improvement in speed with > each generation, too, including the most recent ones). A significant difference at the LUT spec level that I DID see ( and I presume still applies ? ) is that Altera have differing LUT path delays ( all LUT legs are not created equal ), whilst Xilinx treated them all equal. That means the Altera SW/HW can presumably choose the faster legs, where that matters, and so shave 100's of ps off the critical path ? => Faster P&R on otherwise similar silicon ? -jgArticle: 78783
Hi Glen, > I do wonder if the optimal LUT size has changed over the years. > Is there work showing the optimal LUT size as a function of silicon > resources needed to implement such LUTs? Elias Ahmed & Jonathan Rose from the Unversity of Toronto published "The Effect of LUT and Cluster Size on Deep-Submicron FPGA Performance and Density". See http://www.eecg.toronto.edu/~jayar/pubs/ahmed/fpga00.pdf. Elias's M.A.Sc. thesis was on clustering and optimal lut sizes. This paper contains many references to previous work in the area and is probably a good starting point. The paper's conclusion is that a LUT size between 4 and 6 is and cluster sizes of between 3 and 10 LEs are best from a balanced area-delay perspective. If you want higher speed, larger LUTs are better. One suggested area of future research is finding a way to reduce logic levels without the area cost of large LUTs -- and this is what we have done in Stratix II with the ALM. Figure 12 is particularly interesting. I think Guy Lemieux had some work in this area from his PhD -- not sure if its published anywhere yet. At the FPGA 2005 conference in two weeks, the Stratix II logic architecture and some experimental results will be presented in a paper by David Lewis et al. Regards, Paul Leventis Altera Corp.Article: 78784
Hi Austin, No offence, but I don't think you're going to get far with an attack on the logic architecture. I think you should read the paper at FPGA 2005 when you get a chance. It is very informative. > Then comes the other nagging questions: > - are inputs shared? > - how badly does that mess up the results? Irrelevant to the speed question. A simple 6-LUT in Stratix II does not share inputs. LUT input sharing is an area optimization that we employ intelligently to avoid any penalty on performance while reducing number of ALMs required. I should also point out that all our experiments during architecture experimentation are full synthesis + place & route runs on 100+ designs. One thing anyone who works on FPGA logic & routing architecture knows is that intuition isn't worth too much -- you can argue about "will shared inputs hurt things?" until you are blue in the face, but in the end only an experiment will tell the truth. Funny side story: One time during architecture experimentation someone put up a graph of some parameter (I forget what). We sat their and rationalized why the answer would come out that way, and were all content. Then we realized the graph was backwards and the trend was actually the other way around. We could rationalize that answer too... Bottom line: Logic & routing architecture development must involve large amount of experimentation with real cad tools, otherwise you just don't arrive at the right answer. > - given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, > how badly does that increase the delay? Wrong again. The ALM breaks into two independent 4-input LUTs with no delay penalty (ok, maybe a couple ps for a gate load or two) relative to a Stratix-like 4-LUT. > I would claim a properly engineered 6 LUT would improve the overall > performance. A compromise would provide some improvement. A poor > implementation woukd make no difference. Your first claim is correct. And the ALM gives the speed of a 6-LUT, but the extra circuitry added to support fractured modes (2 4-LUTs, shared LUTs, etc.) is minimal and adds a tiny amount of delay to the guts of the LUT. > Should all LUTs be 6 LUTs? Or a mixture of both? In what ratio? Good questions. The reality is that a real design mapped into 6-LUTs doesn't yield all 6-input functions -- it decomposes into a set of functions ranging from 1- to 6-inputs. That is why making a pure 6-LUT architecture is not so great for area -- for those functions that don't use 6-inputs, you are wasting a lot of routing & logic area. That is why we added the fracturing capabilities of the ALM. This makes the ALM more expensive than a straight 6-LUT for implementing 6-input functions, but overall once the distribution of functions is taken into account, the ALM comes out on top. One alternative could be to make an architecture with a hybrid set of LUT sizes. But then you have to wonder whether you've picked the right mix of the two, you have the pain of hetrogeneous floorplanning in layout, you have potential issues with placement, more complicated CAD tools, etc. > Can you use them as SRL? LUT RAM? No, the ALM can't do that. We've argued about that many times in this newsgroup -- SRLs and LUT RAM add cost to the Logic Element. M512 memories are more efficient for many circuits, while SRLs/LUT RAM are more efficient for others. Are SRL/LUT RAM a bad idea? No. Are they a slam dunk? No. > The synthesis tools all have to be retuned, and debugged to take > advantage, so this is not without risk. Yes, that was a risk. We took that risk because we believed the ALM was a large enough win on the performance front to be worth the investment in synthesis and the risk to product success. If the ALM had given us 5% performance, there's no way we would have gone for it. But sometimes you need to take a big jump in architecture to get out of a local minimum in the space of architecture possibilities. We worked with our 3rd party synthesis vendors well in advance of the release of Stratix II, and our own integrated synthesis was used during architecture development and thus was already ready to go. > As for area, a 6 LUT is not all that big as technology shrinks, so some > combinations of variable LUT size, alternate architectures, is in my > opinion, inevitable. Actually, the area of everything (LUTs, routing, RAMs, etc) shrinks as technology does, so I don't think the 4-LUT vs. 6-LUT question changes too much with process. The only effect here is that perhaps as the amount of delay in routing vs. logic moves around with process, the precise answer as to what LUT and Cluster sizes are optimal will shift slightly, but this is probably a small effect. A bigger effect could be evolution in the quality of synthesis and CAD tools, the changing nature of user designs, and advances in routing architecture. > As for speed, the smaller the technology, the less improvement in speed > (ITRS roadmap, and anyone who says differently can be confidently > ignored). For speed, one now has to use triple oxide to get both speed > and static power reduction (eg compare us to S2 at 25C and there is no > difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the > static power!). I haven't seen any worst-case power numbers from you guys Austin. Typical is a marketing number -- how do you define your "typical" silicon? Let's hold off the power conclusions until both companies release final specs. Besides, total power is what matters and you guys have curiously been shying away from dynamic power. Your own web page claims equivalent dynamic power for a Virtex-4 LUT + routing vs. an Stratix II LUT + routing -- but our LUTs implement 25% more logic, and hence there are fewer of them in a given design. Our pin capacitance is 1/2 that of V-4 -- you know what this does for I/O power? Imagine 200 I/Os toggling at 200 Mhz with 6 pF instead of 12 pF loads @ 2.5V (just as an example) -- if I've done my math right that's 1.5W right there. Now there's a strong chance I've done my math wrong (give me a break, its late) but you get the point! > The wonderful thing about standard CMOS, is just that. No one has a > remarkably different or unique process. But one can use standard CMOS > with all of the available tricks, and see a 1/2 to 1/3 reduction in static > power, an improvement in speed, and an improvement in SEU resilience. > Like V4. Yes, there are tricks to employ. But they can cost speed. They can cost area. They can increase wafer costs. All involve trade-offs. In the end, we each picked the tricks we wanted to use. Gate oxide is only one variable to play with, and not the most effective one on the speed vs. leakage trade-off front. > Also, there is room for improvement with the P&R tools True. Both companies have teams beating on this software for lots of performance. But if you're now saying that perhaps future software and a future speed grade will help you catch up on performance, I'm feeling pretty happy with our position. Regards, Paul Leventis Altera Corp.Article: 78785
Hi Jim, > A significant difference at the LUT spec level that I DID see ( and I > presume still applies ? ) is that Altera have differing LUT path delays > ( all LUT legs are not created equal ), whilst Xilinx treated them > all equal. Our LUTs have (significantly) different delays on different inputs. > That means the Altera SW/HW can presumably choose the faster legs, where > that matters, and so shave 100's of ps off the critical path ? > => Faster P&R on otherwise similar silicon ? Yes, the software does take advantage of the variance in LUT delay to optimize the critical path. This is why using 6-LUTs to implement 4-input functions is no worse for speed than using a 4-LUT -- the four fastest inputs of a 6-LUT are basically the same speed as the four inputs of a 4-LUT. Regards, Paul Leventis Altera Corp.Article: 78786
John Maher wrote: > Hi I am using JBITS to generate an anticore for a virtex device. When I run the MAP process I get the error, below. Could anyone give me some insight as to what exactly it means, or even better how I might fix it? > > Thanks -J > > "FATAL_ERROR:Ncd:basnccomp.c:3516:1.29 - Cannot find other bel for unconnected pin on bel <0>.WSGEN:CK of comp coreoutbus<0>. Its current programmed state is : YUSED:0 XUSED:0 F:#RAM:D=0x0000 G:#RAM:D=0x0000 RAMCONFIG:2SHIFTS SRMUX:1 GYMUX:G FXMUX:F Process will terminate. To resolve this error, please consult the Answers Database and other online resources at <http://support.xilinx.com>" Hi John, This error message is reporting an illegal slice configuration in your design. It appears that the problem has to do with an unconnected clock pin. Everything after "Its current programmed state" is just a dump of the slice configuration. You should be able to trace the logic from the component name "coreoutbus<0>". Cheers, BretArticle: 78787
Maybe it signifies the speed your design would run at if you took it out of the fridge and put it in the oven? Syms. <tovijayakumar@yahoo.com> wrote in message news:1107829970.374954.26030@f14g2000cwb.googlegroups.com... > The Xilinx timing report for XPLA3 CPLD shows maximum operating > frequency of 30 MHz for one of our design. But the CPLD is functioning > correctly at 80 MHz. If so what does the Maximum operating frequency > specified in the timing report signify? >Article: 78788
"Symon" <symon_brewer@hotmail.com> wrote in message news:36r100F54rrhtU1@individual.net... > Maybe it signifies the speed your design would run at if you took it out > of the fridge and put it in the oven? > Syms. > <tovijayakumar@yahoo.com> wrote in message > news:1107829970.374954.26030@f14g2000cwb.googlegroups.com... >> The Xilinx timing report for XPLA3 CPLD shows maximum operating >> frequency of 30 MHz for one of our design. But the CPLD is functioning >> correctly at 80 MHz. If so what does the Maximum operating frequency >> specified in the timing report signify? >> Or more likely, the paths that Xilinx sees as critical are not... The tools support multi-cycle timing constraints. Did you give it appropriate constraints, or just let it do it's own thing? JasonArticle: 78789
Oops, I missed one point (thanks Carolyn!). > - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra > logic to almost give you a 6 LUT? How badly does that work? Yes, the ALM is a universal 6-LUT. It can do some functions of 7-inputs, and all functions of 6-inputs. Please refer to http://www.altera.com/literature/hb/stx2/stx2_sii51002.pdf. Page 2-8 is the diagram you want to stare at closely. Paul Leventis Altera Corp.Article: 78790
Solution found. The XCF02S was with its GND pin floating....Actually there was a PCB failure since the trace is almost touching the pad (I would say 1/10th milimeter apart). Problem found in my last attempt to find a solution, when I decided to look and verify every connection in the JTAG chain and on each pin of each device on the board using magnifying lenses. I did a verification before but not in the power pins... So, when something strange happens power pins verification should be near to the top of the check list.... Thanks for your attention.Article: 78791
Thanks to the excellent support from Xilinx this problem has been solved !!! Turns out the Memec-Insight board had a 100 ohm (yes 100 !) pull-up on the TDO line. That basically broke everything. Removing the pullup, got rin of the CRC bit errors and chip- scope appears to work now as well. Thanks a lot for going the extra mile, to all the good folks at Xilinx ! Kind Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 78792
Thank you Mr.Shalin Sheth.Article: 78793
Hi, I am wondering if anyone know a way to translate MATLAB code to VHDL code using System Generator. I know that the MCode block supports a limited set of MATLAB instructions only (therefore I cannot use it for complex operations), and Blackbox block requires VHDL codes itself. How about s-function? Since s-function accepts C codes, is there any way to have System Generator to generate HDL codes using s-function, therefore providing support to high-level programming language? Or is there another method that translates high-level language codes into HDL using System Generator? Thanks in advance.Article: 78794
So the cleanest way to handle this would be to identify the change of the defaults that caused my difference and add this assignment to the 'regular' project file and remove the <project>_assignment_defaults.qpf. Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/ "Subroto Datta" <sdatta@altera.com> schrieb im Newsbeitrag news:1107808734.098840.311310@c13g2000cwb.googlegroups.com... > With QII 4.0, all assignments were consolidated into a single file the > qsf, instead of being stored in several different files (csf, psf, ssf, > fsf) etc. Also as part of QII 4.0, default values of assignments were > no longer stored in the qsf file. In the past all defaults were stored > in the csf file. > > Instead defaults for converted projects were stored in the qdf file in > the project directory, with the name being > <project_name>_assignment_defaults.qdf. Therefore projects which have > been converted from older (i.e before Quartus II 4.0)will have a qdf > file in their project directory. > > When assignments are resolved the default values specified in > <project_name>_assignment_defaults.qdf have a higher priority than > those specified in quartus\bin\assignment_defaults.qdf. Therefore when > you removed the <project_name>_assignment_defaults.qdf file some of the > values of your default settings would have changed, and this explains > the change in results. If you look at the file > quartus\bin\assignment_defaults.qdf you will find a history of the > default changes between releases from 4.1 onwards. An example of the > comments in the QII 4.2 assignmnet_defaults.qdf file is: > > # Default value changes > # > # In 4.2, the default value of assignment DO_MIN_ANALYSIS has changed > to "OFF" > # In 4.1, the default value of assignment FITTER_EFFORT has changed to > "Auto Fit" > > Hope this helps, > Subroto Datta > Altera Corp. > > > Martin Schoeberl wrote: >> I have a project which started with MP2 w. Leonardo and was converted > by >> several versions of Quartus (including several new file types). With > Quartus 4.2 >> I thought the project merely consists of proj.qpf and proj.qsf. > Having all the assignments >> in the .qsf file. >> However, when I compiled the project with the other 'old' project > files removed it resulted >> in a different solution (fmax was 95MHz instead of 100MHz). >> Adding the proj_assignment_defaults.qpf back to the project I got the > original result. >> So the question is: What's this xxx_as._def.qpf for? >> >> Martin >> ---------------------------------------------- >> JOP - a Java Processor core for FPGAs: >> http://www.jopdesign.com/ >Article: 78795
Hi all,
I'm thinking about a new board for JOP (or MB, NIOS). The board should be small and
cheap (below the S3 Starter Kit). It should only contain the absolute necessary parts for a
CPU design. Here is the suggested part list:
FPGA: Cyclone EP1C3 or Spartan XC3S200
256Kx16 15ns SRAM
2 MBit serial Flash
3.3V linear regulation
switching regulator for the core voltage
20MHz clock to the PLL input
I've not yet decided about a X or A device.
A remaining question is about the form factor. I still think it makes sense to build
the board as a module that can be integrated in a board with the peripherals (similar
to the ACEX and Cyclone modules I've done). There are two 'standards' available:
1.) SimmStick, where the boards are designed as the 'old' PC SIMMs (see [1]).
2.) The 'Basic Stamp' design is a board in the form of an old 40-pin (or less) DIL IC.
An example (from a Java processor competitor): [2]
For a Java solution in an FPGA this board should beat the Systronix aJ100 Java processor
modules (JStamp or JStick [3] - they have both form factors) in performance and price.
One nice thing about the SimmStick is that there are plenty of I/O boards already available
(see [4, 5, 6]).
It seems a relative 'old' design, but it's a bus and I can build my first JOP cluster with those
boards ;-)
What do you guys think about this idea? Does it make sense to build a another FPGA board?
[1] http://www.simmstick.com/
[2] http://jstamp.systronix.com/jstamp_photos.htm
[3] http://www.jstik.com/
[4] http://www.dontronics.com/dt.html
[5] http://www.hobbyengineering.com/SectionSS.html
[6] http://www.simmstick.com/simmstic1.htm
Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/
Article: 78796Hi Martin, Nice to see that some of my project are still live - I am the "inventor" of the "SimmStick(tm)" standard :) Please see my SHORT first comments below.. >"Martin Schoeberl" <martin.schoeberl@chello.at> schrieb im Newsbeitrag news:sO%Nd.34738$2e4.30046@news.chello.at... > Hi all, > > I'm thinking about a new board for JOP (or MB, NIOS). The board should be small and > cheap (below the S3 Starter Kit). It should only contain the absolute necessary parts for a > CPU design. Here is the suggested part list: > > FPGA: Cyclone EP1C3 or Spartan XC3S200 > 256Kx16 15ns SRAM -- here I would like to argue a lot! I understand that JOP runs ok in that memory, but... all the rest (if using XC3S200) is uCLinux ready, except memory is not enough, so I would use 1 16bit SDRAM chip, not SRAM XC3S200 is large enough to hold ucLinux ready MicroBlaze setup. > 2 MBit serial Flash -- again the 2MBit is enough for config, not for OS image, so if there would be some means of having more, that would be nice, sure thats an price issue > 3.3V linear regulation > switching regulator for the core voltage for a small FPGA linear regulator is ok, too cheaper sure burns more energy, Trenz S3-1000 module as example has small linear regulator supplying max 0.9A for core > 20MHz clock to the PLL input NEEDED 5V compliance quickswitches !!! all new FPGAs are not 5V tolerant and for both mech standards simmstick and stamp 5V compliance is highly recommended to have, its a pain for manufacturer but a big + for the user > > I've not yet decided about a X or A device. hard decision hugh? answer is simple. BOTH it doesnt cost so much more todo both variants, you may supply more support for either A or X as of your preferences (or customer interest) but from the hardware build expenses its even cheaper (per board) to order a combined pcb patch > A remaining question is about the form factor. I still think it makes sense to build > the board as a module that can be integrated in a board with the peripherals (similar > to the ACEX and Cyclone modules I've done). There are two 'standards' available: > > 1.) SimmStick, where the boards are designed as the 'old' PC SIMMs (see [1]). > > 2.) The 'Basic Stamp' design is a board in the form of an old 40-pin (or less) DIL IC. > An example (from a Java processor competitor): [2] You mean Parallax or those other guys? There are actually several stamp like clones thing. the stamp form factor is more challenging as the pcb are is very constrained :( > For a Java solution in an FPGA this board should beat the Systronix aJ100 Java processor > modules (JStamp or JStick [3] - they have both form factors) in performance and price. > One nice thing about the SimmStick is that there are plenty of I/O boards already available > (see [4, 5, 6]). > It seems a relative 'old' design, but it's a bus and I can build my first JOP cluster with those > boards ;-) hm if you make the simmstick form factor board, here is a deal - I will donate all my leftover simmStick stuff that includes some connectors and protoboards etc, you can use all those boards and stuff as promotional bonus give away for the early customers :) > What do you guys think about this idea? Does it make sense to build a another FPGA board? hm.. I just recently looked at the parallax pricing.. still selling basic interpreter for $49 (or more!) and still doing business. highend stamp are in $99 range! So a fpga plugin module in $99 range, sure it might be business idea still > > [1] http://www.simmstick.com/ > [2] http://jstamp.systronix.com/jstamp_photos.htm > [3] http://www.jstik.com/ > [4] http://www.dontronics.com/dt.html > [5] http://www.hobbyengineering.com/SectionSS.html > [6] http://www.simmstick.com/simmstic1.htm > > Martin > ---------------------------------------------- > JOP - a Java Processor core for FPGAs: > http://www.jopdesign.com/ > >Article: 78797
Hi John, I experienced some wired results on IO configurations as well. The reason was a bug in the synplify synthesis tool. But it only happened for INOUT signals. It resolved the signal connections simply somehow. akuehn meg wrote: > Hi, > > I experience problems with some "normal" IO's(not dual purpose IO's) on > a Xilinx Virtex2p50ff1517. I observe that these IO change value during > configuration and after configuration these IO are not high impedance > as intended, but either high or low. These IO's are part of a > processor interface where the other IO on this bus is high impedance. I > have checked in FPGA Editor and find that there the "strange" IO's are > implemented exactly as the "normal" IO's (the same signal is driving > the output buffer). > > Do any of you have any suggestion to what have gone wrong. Is the chip > damaged or is there something wrong with the configuration procedure. I > tried both slave-serial and JTAG programming but the behaviour is the same. > > John > > >Article: 78798
Hi, I have several nodes in my design (registered nodes) which do not have a "driving" purpose. But for later use of SignalTap (Altera tool to make internal FPGA nodes visible) I do want the synthesizer not to optimize these nodes away. On the other hand I do not want to route these nodes to output pins because of a limited amount of available pins. Is there some possibility to avoid that these registerd not used nodes are optimized away ? Thank you for your suggestion. Rgds AndréArticle: 78799
Hi has any one some hints or tips how to get an Virtex4 LX25-ES configured from SystemACE? we can configure from iMpact and if we load the uclinux kernel from XMD it works too. but now when I try to load the uclinux image from CompactFlash then there are problems if the FPGA is configured by impact then there will always be random sector read errors when attempting to load the image.bin from CompactFlash. On ML300 I had to load from CF in order to access the CF, but with V4LX the FPGA config from CompactFlash doesnt seem to work, the status led blinks once and then the error led goes on. I assume it is the TDO tristate problem with -ES samples, but... ML401 has systemACE as well and that works! So whats the trick ?? Antti
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