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
"rickman" <gnuarm@gmail.com> wrote in message news:4fb11a6d-d334-48ae-911c-5c6f006987a7@s22g2000vbb.googlegroups.com... > My customer was talking about running PC Linux on a CPU in an FPGA. I > believe the one big requirement is that there has to be a MMU. Which > of the three FPGA vendor's cores are available with a Linux supported > MMU? I cores I know about from vendors are uBlaze, NIOS and LM32. I > don't think Actel has one, they seem to be using ARM. Then of course > there are the gazillion open source cores at all levels of functioning > and support, everything from commercial grade to "What, me worry?" > > Which of these are practical for a commercial project? > > Rick Check out the Leon3 core (Sparc V8), although not in your favourite language it is very well supported (includes Linux). http://www.gaisler.com/cms/ Hans. www.ht-lab.comArticle: 147201
Hi, HT-Lab wrote: > Check out the Leon3 core (Sparc V8), although not in your favourite language it > is very well supported (includes Linux). > http://www.gaisler.com/cms/ it's a good but *big* core, it needs lost of gates and it's not very speedy compared to the average soft cores. So it's going to cost Rick's client too much, an add-on module with an Atmel ARM9 would be faster and cheaper to get on the field... but it's only my opinion. http://en.wikipedia.org/wiki/Soft_processor has a quite good list, it is missing several like Hans' 8086 clone but otherwise worth a check. Rick, please keep us informed about your choice and the reasons that motivated it :-) > Hans. > www.ht-lab.com yg -- http://ygdes.com / http://yasep.orgArticle: 147202
On 17 Apr, 17:03, whygee <y...@yg.yg> wrote: > rickman wrote: > > My customer was talking about running PC Linux on a CPU in an FPGA. =A0= I > > believe the one big requirement is that there has to be a MMU. =A0Which > > of the three FPGA vendor's cores are available with a Linux supported > > MMU? =A0I cores I know about from vendors are uBlaze, NIOS and LM32. = =A0I > > don't think Actel has one, they seem to be using ARM. =A0Then of course > > there are the gazillion open source cores at all levels of functioning > > and support, everything from commercial grade to "What, me worry?" > > > Which of these are practical for a commercial project? > > AFAIK, MICO32 seems to work There isn't an MMU for Mico32. JonArticle: 147203
I have re-listed it http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=290426137491Article: 147204
Am 17.04.2010 16:58, schrieb rickman: > My customer was talking about running PC Linux on a CPU in an FPGA. I > believe the one big requirement is that there has to be a MMU. Which > of the three FPGA vendor's cores are available with a Linux supported > MMU? I cores I know about from vendors are uBlaze, NIOS and LM32. I > don't think Actel has one, they seem to be using ARM. Then of course > there are the gazillion open source cores at all levels of functioning > and support, everything from commercial grade to "What, me worry?" > > Which of these are practical for a commercial project? The OpenRISC 1000 is a free architecture that can run Linux and has been used in commercially ASICs and FPGAs. There is a GNU toolchain (i.e. gcc port, etc). PhilippArticle: 147205
Hi people. This problem has been driving me batty now for a while. I have spent ages tracking down a bug in my VHDL only to find there is no bug at all - just that the initialisation data I have pre-set into a VIRTEX-4 BRAM does not appear to be there after the FPGA has been loaded. I have tried a number of different experiments - and finally stripped the logic back to a clock circuit, a few switches and LED's and a single BRAM instance with the same problem... I am using a HydraXC-30 module with a Xilinx VIRTEX-4 FPGA. I am using Xilinx WebPACK version 11.1 to configure the device. I am then transferring the bit image onto an SD card and booting the FPGA from there - as is normal with the HydraXC-30. Even though I have instantiated a BRAM with the INIT_XX attributes set - the BRAM always seems to boot up without the initialisation data present. The RAM does (however) behave correctly (i.e. I can write data into a memory cell and I can read the same data back out of it again at some point in the future). I have used the FPGA editor and I can open the instance of the BRAM and see the init data within the window OK. I have even dumped out the bit file as ASCII, changed a byte in my initialisation attributes and dumped the bit file again. I can see differences within the two bit files indicating that the WebPACK tools have stored my data into the bitstream. I have also tried rebuilding the bit file without making any changes to the initialisation attributes and the only thing that changes in the bit file is the header right at the front of the bit file (date and time of build) - just to make sure I am not confusing myself. Has anyone else come across this problem? Are there any build options or configuration options that could disable loading the BRAM initialisation data into the FPGA? WebPACK is using the default stepping for the VIRTEX-4 (1) but the FPGA itself maybe stepping 2 (part number XC4VLX25 SF363CNQ0533 DD16169A 10C). Changing the stepping within WebPACK causes it to change my clock DCM to "auto calibration" mode and my clock circuit refuses to work after that! I haven't looked into this problem further - but I was under the impression that stepping levels should be upwardly compatable (i.e. code generated for stepping 1 should work on stepping 2). Any help gratefully received, DaveArticle: 147206
>Hi people. >Even though I have instantiated a BRAM with the INIT_XX attributes set >- the BRAM always seems to boot up without the initialisation data >present. The RAM does (however) behave correctly (i.e. I can write >data into a memory cell and I can read the same data back out of it >again at some point in the future). > >Any help gratefully received, > >Dave > > Make sure your init file size EXACTLY matches your declared ram size. If it's off either way you get no init and a warning message in the log file John --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147207
On 15 Apr, 15:17, Martin Thompson <martin.j.thomp...@trw.com> wrote: > Fred <fred__blo...@lycos.com> writes: > > On Apr 12, 2:04=A0pm, Fred <fred__blo...@lycos.com> wrote: > >> Can anyone recommend a cross beween reading material and reference > >> material for MPEG coding? > > >> I am familiar with JPEG, and the JFIF file structure and would like to > >> know more about MPEG, preferably to include MPEG-4 with a view to > >> coding MPEG4 streams. > > > Can anyone suggest an alternative group to ask the question? > > comp.dsp maybe? > > For reference material, the MPEG-4 Wikipedia page has links to all the > ISO standards documents. =A0More than you could ever want to know I > imagine! =A0MPEG-4 covers an awful lot of ground! > > For something that's a "cross-between reading and reference material" > as you asked, I think you'll have to give more idea as to what level > you want to read at, sorry! > > Cheers, > Martin > > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w= ww.conekt.net/electronics.html Thanks very much. In the past I have found ISO standards unreadable though good for reference. I wanted more a book I could read on trains or waiting for appointments. But a book where I would get more than an overview with some depth. I am very aware that H.264 is very involved but would like to be in a position where I could write some code, or at least understand the basis on which existing code has been written.Article: 147208
Fred <fred__bloggs@lycos.com> writes: > Thanks very much. In the past I have found ISO standards unreadable > though good for reference. I wanted more a book I could read on > trains or waiting for appointments. But a book where I would get more > than an overview with some depth. > > I am very aware that H.264 is very involved but would like to be in a > position where I could write some code, or at least understand the > basis on which existing code has been written. In that case, I'm afraid I'm short on suggestions, never having delved much beneath the "visible surface" of that sort of compression. Sorry! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 147209
rickman <gnuarm@gmail.com> writes: > My customer was talking about running PC Linux on a CPU in an FPGA. I > believe the one big requirement is that there has to be a MMU. Which > of the three FPGA vendor's cores are available with a Linux supported > MMU? I cores I know about from vendors are uBlaze, NIOS and LM32. I > don't think Actel has one, they seem to be using ARM. Then of course > there are the gazillion open source cores at all levels of functioning > and support, everything from commercial grade to "What, me worry?" > > Which of these are practical for a commercial project? Certainly Microblaze has an MMU suitable for full-blown Linux use, and NIOS also does I believe. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 147210
On 15 Apr, 15:42, "Pete Fraser" <pfra...@covad.net> wrote: > "Fred" <fred__blo...@lycos.com> wrote in message > > news:e639ddb6-ff7b-4337-a37a-a23d93f35bdc@11g2000yqr.googlegroups.com... > > > Can anyone recommend a cross beween reading material and reference > > material for MPEG coding? > > > I am familiar with JPEG, and the JFIF file structure and would like to > > know more about MPEG, preferably to include MPEG-4 with a view to > > coding MPEG4 streams. > > Can anyone suggest an alternative group to ask the question? > > Try comp.compression. > > MPEG-4 covers a vast amount of material. > It sounds like you're interested in video coding, so you're > probably interested in MPEG-4 part 2 and / or MPEG-4 > part 10 (a.k.a. AVC or H.264). > > Each of these offers a variety of tools that can be > used to increase compression efficiency, at the expense > of increased complexity. H.264 is more efficient and > more complex than MPEG-4 part 2. > > Are you thinking of building an encoder or decoder in > FPGAs? This is a relatively big deal. The decoder would > be much easier than the encoder, so that might be a good > place to start. > > I have H.264 and MPEG-4 Video compression by > Iain Richardson, and The MPEG-4 Book by Pereira > and Ebrahimi. Both are reasonable introductions. > > It used to be possible to download some ITU documents > for free from the ITU. It may still be. If so, you should > download the H.264 specification. The ITU doesn't have > a version of MPEG-4 part 2, so you'll have to pay the ISO > for that. You might be able to download a copy of H.263 > from the ITU for free. This has a slight overlap with > MPEG-4 part 2 which has a compatability (short header) > mode that is essentially H.263. > > Pete I'm most interested in H.264 and not sure of the difference between this and H.263. I have looked at reviews of both books and feel they both have shortcomings. I notice that Richardson has a new version coming out soon which may well address some of the complaints. There seem very few up to date books on the subject to choose from. Many thanks.Article: 147211
hi all I have a strange problem during FPGA working.PROM files can be dowmloaded to Configuration flash XCF32P successfully,level of Dedicated configuration pins DONE and INIT_B is both high,FPGA works normally. But after a time FPGA can not works,level of pin DONE changes to be low!! level of pin INIT_B changes to be also low sometimes. I am at a loss. best regards! wert --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147212
Hello all I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit (MCU). The MCU is now obsolete (it's from the late 1980s). The firmware is compiled from several thousand rows of assembly language. It would take a long time to understand the code and re-program it in C. So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware code without any changes to the code. Any one here had any luck with this kind of problem? From puiterl@notaimvalley.nl Mon Apr 19 07:12:53 2010 Path: unlimited.newshosting.com!s03-b32.iad!npeersf02.iad.highwinds-media.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.com!newshosting.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!194.109.133.84.MISMATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Message-Id: <4bcc64e5$0$22942$e4fe514c@news.xs4all.nl> From: Paul Uiterlinden <puiterl@notaimvalley.nl> Subject: Re: I'd rather switch than fight! Newsgroups: comp.lang.vhdl,comp.arch.fpga,comp.lang.verilog Followup-To: comp.lang.vhdl Date: Mon, 19 Apr 2010 16:12:53 +0200 References: <203362d3-a588-4615-9431-bc8c2a9abb08@v13g2000vbf.googlegroups.com> <84bb62a7-6a76-4a34-a187-1dcc29ea4d8c@b23g2000yqn.googlegroups.com> <hq5scg$ee8$1@naig.caltech.edu> <4bc6cffd$0$2006$8404b019@news.wineasy.se> <jk2es59ka279hufgv995q7u4kuf4gror93@4ax.com> <5a4d713f-80dc-4aa9-a43a-cfef7075f018@o24g2000vbo.googlegroups.com> <4bc773f1$0$11801$8404b019@news.wineasy.se> <00f1adea-104b-4a57-944d-773d49fd64fc@k33g2000yqc.googlegroups.com> <e31fs558jmaffop4ulomrm1d9992nu77vp@4ax.com> <2f5ac6a4-f5ce-408c-b880-963f46786d63@x3g2000yqd.googlegroups.com> <7baca854-0f68-4807-8e0f-b25cfc3bce4f@w17g2000yqj.googlegroups.com> Organization: AimValley User-Agent: KNode/0.10.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 40 NNTP-Posting-Host: 195.242.97.150 X-Trace: 1271686373 news.xs4all.nl 22942 puiterl/[::ffff:195.242.97.150]:55649 X-Complaints-To: abuse@xs4all.nl Xref: unlimited.newshosting.com comp.lang.vhdl:35767 comp.arch.fpga:100592 comp.lang.verilog:18323 X-Received-Date: Mon, 19 Apr 2010 14:13:54 UTC (s03-b32.iad) Andrew FPGA wrote: > Interesting in the discussion on myHdl/testbenches, no-one raised > SystemVerilog. SystemVerilog raises the level of abstraction(like > myHdl), but more importantly it introduces constrained random > verification. For writing testbenches, SV is a better choice than > MyHdl/VHDL/Verilog, assuming tool availablility. And assuming availability of financial means to buy licenses. And assuming availability of time to rewrite existing verification components, all of course written in VHDL. And assuming availability of time to learn SV. And assuming availability of time to learn OVM. And ... Oh man, is it because of the seasonal change that I'm feeling so tired, or is it something else? ;-) > It would seem that SV does not bring much to the table in terms of RTL > design - its just a catchup to get verilog up to the capabilities that > VHDL already has. Indeed. I agree that SV seems to give most room for growth in the verification side. VHDL is becoming too restrictive when you want to create really reusable verification parts (reuse verification code from block level at chip level). More often than not, the language is working against you in that case. Most of the time because it is strongly typed. In general I prefer prefer strongly typed over weakly typed. But sometimes it just gets in your way. For design I too do not see much advantage of SV over VHDL, especially when you already are using VHDL. So then a mix would be preferable: VHDL for design, SV/OVM for verification. -- Paul Uiterlinden www.aimvalley.nl e-mail addres: remove the not.Article: 147213
Smith schrieb: > I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit > (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language. It > would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. Unless you have an FPGA implementation of /exactly/ the 537, it probably won't work. Remember that this MCU also contains very many special function registers that most probably are used by the software, but not covered by the available, more "generic", IP cores. Several thousand lines of 8051 assembly, however, don't appear too much to port. If you have the sources (as it sounds), you can probably find the SFR-relevant code sections rather easily and port the application (still in assembly language) to your new implementation on any current 8051 - or an IP-core in an FPGA. Unless you have an FPGA in your new design anyway, I would however suggest to look for a new flash-based 8051 MCU. It will probably be less porting expense. Have a closer look /why/ the 537 was choosen for this application - was it the number of ports, or any special peripheral hardware function? Get a modern chip that fits these requirements best. "Without any changes to the code" is not possible IMHO. TilmannArticle: 147214
On Mon, 19 Apr 2010 15:53:25 +0200, "Smith" <smith@donotwantmail.com> wrote: >Hello all > > > >I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit >(MCU). The MCU is now obsolete (it's from the late 1980s). > > > >The firmware is compiled from several thousand rows of assembly language. It >would take a long time to understand the code and re-program it in C. > > > >So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware >code without any changes to the code. There are lots and lots of MCS-51 microcontrollers still on the market. Silicon Labs, Atmel, and Infineon among many others. I'd look there first, before committing to instantiating an FPGA core. -- Rich Webb Norfolk, VAArticle: 147215
Do you need one 80537, a few, or lots of MCUs?Article: 147216
Look here: http://www.littlediode.com/components/80C537_Integrated_Circuit.html?NO_COOKIE_WARNING=2&ti=ca697e2b03146363b5a9601ab6592a49&xid=60b420f64a0bf7ac68d8779fdb2b8008Article: 147217
I need about 100-200 parts. "Stefan Brröring" <stefan___@broering.de> wrote in message news:4bcc68c8$0$3291$8e6e7893@newsreader.ewetel.de... > Do you need one 80537, a few, or lots of MCUs?Article: 147218
Smith wrote: > Hello all > > I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit > (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language. It > would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. > > Any one here had any luck with this kind of problem? I'm with the rest of the folks here: (a) Why try to rewrite this in C? Why not port this to a new 8051 using the existing code as a base? If the code is well written and commented then the only parts that will have to be changed will be the parts that talk to hardware, although depending on the code and the application this may take some head-scratching. (b) You're probably far better off to make this work with some new spin of an 8051, with the peripherals that you need to get the job done. (c) I could easily see trying to exactly replicate an old application, complete with snazzy peripherals and maybe timing loops, to be a never-ending hassle. You know the old saw about the last 10% of the work taking 90% of the time? I think this would be a way to design a project where the last 1% of the work takes 99% of the time. If I'm wrong, it'd only be because you'd see the last 0.1% of the work taking 99.9% of the time. Software is cool because it's easy to change, so you can use it to help your product dodge around changing marketing requirements and hardware issues. Chaining your whole project to a large chunk of dead code is just asking for a nightmare. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 147219
Thanks to everybody for your incredible help. I've been reading more about my board, and Guy is right. It seems that the only way to work with the compact is using the systemACE. Working with systemACE seems much more easier than programming the entire driver to use the compact. You only have to take care of reading and writing some registers to configure and use the systemACE. Reading the available documentation i found one question that i couldn't answer and is where the information that is going to be read or write from the compact is saved inside the fpga. Anybody has any idea? Thanks -- bluds --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147220
Hi, does anyone know if there is such a thing as clock IO for Xilinx FPGA?? If i were to design my own PCB board with an FPGA on it, do i necessarily have to route the clock from the on-board oscillator directly only to the clock IO pins? din consider this before, but thought i get some opinions to be sure thanks ChrisArticle: 147221
On Apr 19, 7:43=A0am, "Smith" <sm...@donotwantmail.com> wrote: > I need about 100-200 parts. > > "Stefan Brr=F6ring" <stefan...@broering.de> wrote in message > > news:4bcc68c8$0$3291$8e6e7893@newsreader.ewetel.de... > > > Do you need one 80537, a few, or lots of MCUs? Let's go with 200 parts. Someone pointed you to a web site that listed the cost at roughly US $50 each at that quantity. You would probably spend more that $10,000 moving the existing code to whatever new solution you found. So unless you can find a replacement for less than zero dollars, it's less expensive to pay the (exorbitant) per-chip price. Even though I think it would be "fun" to design it out, it's not responsible engineering. RKArticle: 147222
On Apr 19, 9:49=A0am, chrisdekoh <chrisde...@gmail.com> wrote: > Hi, > > does anyone know if there is such a thing as clock IO for Xilinx > FPGA?? If i were to design my own PCB board with an FPGA on it, do i > necessarily have to route the clock from the on-board oscillator > directly only to the clock IO pins? > > din consider this before, but thought i get some opinions to be sure > > thanks > Chris Yes, certain pins are defined as clock pins. You need to read the "Package and Pinout User Guide" for the specific family that you are using for more information. Ed McGettigan -- Xilinx Inc.Article: 147223
On Apr 14, 3:23=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote: > > Seriously, that's why conversion to VHDL/Verilog gets so much > attention. It allows you to view MyHDL simply as a more effective > or fun way to create your trusted VHDL/Verilog design. > > Therefore, no need to ask nor tell anyone. If you're intrigued, > just do it, and do it as a good engineer: start with a simple > but relevant module, not with a whole design. After conversion, > few will be able to tell (you may even get praise for the > code quality :-)). And do what? Be forced into a design/coding paradigm that is the least common denominator of verilog and vhdl? No thanks, I don't need or want another code generator. Code conversion is only applicable if you never have to read it or maintain it in its converted form. I can't rely on myhdl in order to maintain the source. AndyArticle: 147224
"Smith" <smith@donotwantmail.com> wrote in message news:4bcc6082$0$45179$afc38c87@read01.usenet4all.se... > Hello all > I need to run an old firmware for a Siemens SAB 80C537 microcontroller > unit (MCU). The MCU is now obsolete (it's from the late 1980s). > > The firmware is compiled from several thousand rows of assembly language. > It would take a long time to understand the code and re-program it in C. > > So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware > code without any changes to the code. > > Any one here had any luck with this kind of problem? I'd try tweaking firmware first. Looks like this one is not standard 8051 deriviative. Has 32bit math MDU and 8 DPTR registers. First thing I'd do is see if these odd features are being used. If not, it would be easy to port to another 8051 derivative. If so, porting challenge could range from a minor hassle to impossible. Then C port might be way to go. I'd get a good firmware engineer to evaluate code before moving forward.
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