Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Sep 9, 11:56=A0am, "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Hi, i am using a FPGA PCI board on my project. I was looking at OpenCores > and i found 2 interesting cores. PCI_Bridge and PCI_Target (pci32tlite_oc= ). > > Any one here have any experience with one or both boards? Are they > different on performance? Are they reliable? I was looking on OpenCores > forum and a user was having a problem using PCI_Target on Windows. He had > success to use it on Linux (i will be using on Linux too). He was able to > use PCI_Bridge at both OS with no problem but he wrote that PCI_Bridge is > too slow. PCI_Bridge looks so much complete, whay it would be slower? I w= as > unconfortable using PCI_Target becouse it is VHDL and PCI_Bridge is > Verilog, and i dont have much experience with VHDL (actualy very little). > So what would you guys sugest me? Any comment about both Cores? > > Thank you!! =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I don't know for sure, but judging from the names, they do different things. A bridge connects two PCI busses. A target should have PCI on one side and a different bus on the other to connect to some device or a function internal to the FPGA. Which of these do you need? One of the advantages of open cores is that you can root around in the guts. Do you understand how they work? What software do you expect to use with them? The speed issue may be in the software. RickArticle: 148901
On Sep 9, 10:25=A0am, Andy <jonesa...@comcast.net> wrote: > On Sep 9, 7:35=A0am, rickman <gnu...@gmail.com> wrote: > > > > > On Sep 8, 7:23=A0pm, Socrates <mail...@gmail.com> wrote: > > > > > In terms of FPGAs, the BS might indicate that you can program in a = HDL, > > > > MS that you understand HDLs in general, and PhD that you understand= how > > > > HDLs actually work. > > > > Well, thats the point! I would like to go for MSEE somewhere in > > > Europe. Some people recommends me RWTH @ Germany. Maybe any other > > > offers in other places? :) I am mainly pointing to FPGA design > > > studies. > > > What would you like to learn about FPGAs? =A0I can't see how FPGAs woul= d > > be a topic of study in any level of school, not just graduate school. > > FPGAs are where you would apply the general design theory you learn as > > an undergraduate, but I don't see how there is anything you could > > learn beyond that which would be a topic of "study". =A0Typically areas > > of application are what you learn after you get out of school. > > > When I got my undergraduate, they taught us Karnaugh maps and various > > methods of logic minimization as well as describing how PLAs worked. > > But PLAs were a part of one class, not a topic of study. =A0On the othe= r > > hand, I took a class in more advanced logic design techniques which > > covered things like string recognizers, state equivalence (in FSMs) > > and asynchronous logic, all of which are applicable to PLAs as well as > > FPGAs. > > > What would be the topics of study in FPGA design? =A0I can't think of > > anything I have learned about FPGAs that would be considered college > > level material. =A0Or are you thinking of how to design FPGA > > architectures rather than FPGA usage? > > > I don't see HDL and FPGA as being synonymous as HDLs apply to all > > logic devices, not just FPGAs. > > > Rick > > When I was in college in the early/mid 80's, we learned the Karnaugh > maps, QM methods, etc. and how to implement logic functions with muxes > and decoders and other SSI devices (PALs were still pretty new, and > were addressed in a couple of labs). We did state machines with > registered PROMs. On the job, later in that decade, I learned more > about PALs, and CUPL and ABEL programming. Then the earliest days of > FPGAs were schematic capture, and many of those old SSI design methods > were called upon again, but with more rigid clocking rules. Then HDLs > came along, and we started coding our schematics in VHDL (what I call > netlisting in VHDL), which was only marginally more productive. But > gradually we got more comfortable with higher levels of abstraction in > HDL, and focusing on describing behavior (on a cycle-by-cyle basis) > rather than physical structure, and on more advanced verification > techniques. > > My point is, FPGAs are the medium in which much of digital design is > accomplished today, and teaching design techniques that are applicable > to that medium (as opposed to SSIs or PALs) is certainly within the > realm of undergraduate courses, particularly lab courses, where using > an FPGA development board allows students to accomplish much more > complex logic designs in the time available. Even in a non-lab > environment, working with FPGAs, HDLs and testbenches lays a > foundation that I believe should be a part of a good undergraduate > education. > > Andy And are those generic design techniques not learned in school? Of course they are taught. They just don't have specialized courses in FPGA design because most of these techniques are not unique to FPGAs. HDL is the only part of FPGA design that is not widely used in other areas and that is also used, and in fact was invented for, chip design. The "real" FPGA specific design techniques are things like inference of specific structures (memory, MACs, etc) and how to meet timing using static timing constraints. These are not taught to any degree because they are not subjects of study, but rather just tools. They may be exposed to them in the lab classes, but they aren't likely to show up on a lecture. Heck, I remember the professor mentioning that when you look at digital signals in the lab they will have all sorts of noise on them, mostly the high levels being sensitive to the other outputs on the same chip. He drew a wavering line on the board and moved on. Later I had to learn about signal integrity on my own. Today signal integrity is an area that you can become a well paid expert on, ask Dr. Johnson. But as far as I know, there are still no classes on SI. They expect you to learn E&M theory and then apply it. Same with FPGAs. You learn to write HDL, but most of FPGA design is something they expect you to learn by doing. RickArticle: 148902
> >I don't know for sure, but judging from the names, they do different >things. A bridge connects two PCI busses. A target should have PCI >on one side and a different bus on the other to connect to some device >or a function internal to the FPGA. > >Which of these do you need? > >One of the advantages of open cores is that you can root around in the >guts. Do you understand how they work? What software do you expect >to use with them? The speed issue may be in the software. > >Rick > I will be using it on a Spartan-III FPGA. Well not exactly, PCI_Bridge is a bridge between PCI BUS and Wishbone Bus. But it does have a PCI Master and PCI Slave module. The PCI Target is a bridge too but as i understood just have a PCI Slave (and a WB Master on the other hand of the bridge). The program and drivers are going to be made by me. I will be running on Linux. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148903
rickman <gnuarm@gmail.com> wrote: > On Sep 8, 7:23 pm, Socrates <mail...@gmail.com> wrote: >> > In terms of FPGAs, the BS might indicate that you can program in a HDL, >> > MS that you understand HDLs in general, and PhD that you understand how >> > HDLs actually work. >> Well, thats the point! I would like to go for MSEE somewhere in >> Europe. Some people recommends me RWTH @ Germany. Maybe any other >> offers in other places? :) I am mainly pointing to FPGA design >> studies. > What would you like to learn about FPGAs? I can't see how FPGAs would > be a topic of study in any level of school, not just graduate school. > FPGAs are where you would apply the general design theory you learn as > an undergraduate, but I don't see how there is anything you could > learn beyond that which would be a topic of "study". Typically areas > of application are what you learn after you get out of school. I think I agree with this. The subject is digital logic and logic design, with FPGAs as a practical and affordable way to implement such designs. In addition, HDL is a way to write down logic that gets too complicated to fit drawn on gates on a single piece of paper. > When I got my undergraduate, they taught us Karnaugh maps and various > methods of logic minimization as well as describing how PLAs worked. > But PLAs were a part of one class, not a topic of study. On the other > hand, I took a class in more advanced logic design techniques which > covered things like string recognizers, state equivalence (in FSMs) > and asynchronous logic, all of which are applicable to PLAs as well as > FPGAs. I don't know how many of those they still teach. I do believe that asynchronous (dual-rail, self-timed logic) is a lost art by now. I never got to take the class, but I do remember others who did explaining how dual-rail logic works. > What would be the topics of study in FPGA design? I can't think of > anything I have learned about FPGAs that would be considered college > level material. Or are you thinking of how to design FPGA > architectures rather than FPGA usage? Well, there do have to be a few of those. Though I think by now, it is more a marketing issue than a design issue. I could come up with many FPGA designs, but they would never get past any marketing department. I have wondered about an FGPA specifically for dual-rail asynchronous logic. No useless FF's, and routing optimized for dual rail signaling. > I don't see HDL and FPGA as being synonymous as HDLs apply to all > logic devices, not just FPGAs. -- glenArticle: 148904
"Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: >Hi, i am using a FPGA PCI board on my project. I was looking at OpenCores >and i found 2 interesting cores. PCI_Bridge and PCI_Target (pci32tlite_oc). > > >Any one here have any experience with one or both boards? Are they >different on performance? Are they reliable? I was looking on OpenCores >forum and a user was having a problem using PCI_Target on Windows. He had >success to use it on Linux (i will be using on Linux too). He was able to >use PCI_Bridge at both OS with no problem but he wrote that PCI_Bridge is >too slow. PCI_Bridge looks so much complete, whay it would be slower? I was >unconfortable using PCI_Target becouse it is VHDL and PCI_Bridge is >Verilog, and i dont have much experience with VHDL (actualy very little). >So what would you guys sugest me? Any comment about both Cores? AFAIK the timing constraints may be the biggest issue besides whether the core works correct. You should be okay if you make sure the input and output flipflops are inside the IOBs. You can force the latter with timing constraints and check it using the floorplanner on the routed design. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 148905
http://www.centredaily.com/2010/09/01/2182784_vhdl-ieee-1076-2008-is-alive-and.html Is Mentor a VHDL-2008 zombie ? Cheers, hssigArticle: 148906
On Sep 9, 1:00=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > On Sep 8, 7:23=A0pm, Socrates <mail...@gmail.com> wrote: > >> > In terms of FPGAs, the BS might indicate that you can program in a H= DL, > >> > MS that you understand HDLs in general, and PhD that you understand = how > >> > HDLs actually work. > >> Well, thats the point! I would like to go for MSEE somewhere in > >> Europe. Some people recommends me RWTH @ Germany. Maybe any other > >> offers in other places? :) I am mainly pointing to FPGA design > >> studies. > > What would you like to learn about FPGAs? =A0I can't see how FPGAs woul= d > > be a topic of study in any level of school, not just graduate school. > > FPGAs are where you would apply the general design theory you learn as > > an undergraduate, but I don't see how there is anything you could > > learn beyond that which would be a topic of "study". =A0Typically areas > > of application are what you learn after you get out of school. > > I think I agree with this. =A0The subject is digital logic and > logic design, with FPGAs as a practical and affordable way > to implement such designs. =A0 > > In addition, HDL is a way to write down logic that gets too > complicated to fit drawn on gates on a single piece of paper. > > > When I got my undergraduate, they taught us Karnaugh maps and various > > methods of logic minimization as well as describing how PLAs worked. > > But PLAs were a part of one class, not a topic of study. =A0On the othe= r > > hand, I took a class in more advanced logic design techniques which > > covered things like string recognizers, state equivalence (in FSMs) > > and asynchronous logic, all of which are applicable to PLAs as well as > > FPGAs. > > I don't know how many of those they still teach. =A0I do believe > that asynchronous (dual-rail, self-timed logic) is a lost art > by now. =A0I never got to take the class, but I do remember others > who did explaining how dual-rail logic works. > > > What would be the topics of study in FPGA design? =A0I can't think of > > anything I have learned about FPGAs that would be considered college > > level material. =A0Or are you thinking of how to design FPGA > > architectures rather than FPGA usage? > > Well, there do have to be a few of those. =A0Though I think by now, > it is more a marketing issue than a design issue. =A0I could come > up with many FPGA designs, but they would never get past any > marketing department. > > I have wondered about an FGPA specifically for dual-rail > asynchronous logic. =A0No useless FF's, and routing optimized > for dual rail signaling. > > > I don't see HDL and FPGA as being synonymous as HDLs apply to all > > logic devices, not just FPGAs. > > -- glen I'm not familiar with dual-rail async logic. What we learned was just how to implement state machines in async logic which means every state transition has to be designed and implemented in specific gates so that the transitions go through a known sequence of meta-states as the logic changes. At least that is what I recall about it. It was a looooonnnng time ago and I never used it. I've only seen one async design that that used a chip (again some thirty years ago) that was designed to implement async logic. The advantage was it should have been faster to respond to an input change since it didn't wait for a clock. It is a little scary thinking about my early FSM designs. I was working for some 10 years or more before I learned about meta- stability. In fact, I worked on a TTL logic design in one of my first jobs that was not working right because of a problem with unsync'ed inputs. I don't know that it was a meta-stability issue, but it likely would have shown up if the more obvious problem wasn't occurring more often. Military radar jamming equipment IIRC. I expect it worked well enough to do the job to spec. RickArticle: 148907
On Sep 9, 2:26=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > "Sink0" <sink00@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >Hi, i am using a FPGA PCI board on my project. I was looking at OpenCore= s > >and i found 2 interesting cores. PCI_Bridge and PCI_Target (pci32tlite_o= c). > > >Any one here have any experience with one or both boards? Are they > >different on performance? Are they reliable? I was looking on OpenCores > >forum and a user was having a problem using PCI_Target on Windows. He ha= d > >success to use it on Linux (i will be using on Linux too). He was able t= o > >use PCI_Bridge at both OS with no problem but he wrote that PCI_Bridge i= s > >too slow. PCI_Bridge looks so much complete, whay it would be slower? I = was > >unconfortable using PCI_Target becouse it is VHDL and PCI_Bridge is > >Verilog, and i dont have much experience with VHDL (actualy very little)= . > >So what would you guys sugest me? Any comment about both Cores? > > AFAIK the timing constraints may be the biggest issue besides whether > the core works correct. You should be okay if you make sure the input > and output flipflops are inside the IOBs. You can force the latter > with timing constraints and check it using the floorplanner on the > routed design. > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > nico@nctdevpuntnl (punt=3D.) > -------------------------------------------------------------- I read a post by someone, likely in this group, about the core they wrote which was able to clock at 66 MHz while the Xilinx core could only clock at a little over 33 MHz and needed some careful integration to do that. Anyone remember that post? I think he may have been discussing his core with Xilinx, I assume because they wanted to license it. RickArticle: 148908
On Sep 9, 5:39=A0am, rickman <gnu...@gmail.com> wrote: > On Sep 9, 6:30=A0am, Robert Miles <robertmiles...@gmail.com> wrote: > > > > > On Sep 6, 4:42=A0pm, "langw...@fonz.dk" <langw...@fonz.dk> wrote: > > > > On 6 Sep., 17:19, Rich Webb <bbew...@mapson.nozirev.ten> wrote: > > > > > On Sun, 05 Sep 2010 21:31:12 -0400, Rob <noth...@nowhere.com> wrote= : > > > > >What has happened in the last year or so? =A0This group never had = this > > > > >much spam when Peter was a regular contributor. =A0I thought perha= ps he > > > > >had a hand in keeping this group free from the crap? > > > > > Actually, going back over the logs [*] it looks like the rate of sp= am in > > > > this group has been decreasing. There was a peak period from late A= ugust > > > > until early December 2009 where there were about 50-60 spam posting= s per > > > > week. By February of this year, the rate had fallen to below 30/wk = and > > > > then to the low 'teens and single digits since then. Hardly more th= an > > > > one/day most recently. > > > > > [*] I run Hamster Playground 2.5 as a local server to pre-filter th= e > > > > news feed, upstream of my news reader. I don't add *every* faux Pra= da > > > > handbags!!!! posting to the filters but wait until a given spam sou= rce > > > > becomes "noticeable," so the true spam rate will be slightly higher= than > > > > and to the left of what the logs captured. > > > > looking at groups.google.com the latest post I see looking like spam > > > is a reply to something about natural gas for your car from august 13= . > > > > that ain't bad > > > > -Lasse- Hide quoted text - > > > > - Show quoted text - > > > Perhaps because I've recently added this newsgroup to those I report > > the Google Group spam for. > > I was reporting spam to Google for a while and I never saw a result of > my efforts. > > Rick I don't believe that Google is interested in decreasing the spam. Google charges for advertising. I would guess that what they charge is related to the activity in the group. Spam counts as activity, reading and flagging posts is even more activity. Google's motivation is what? Money. Perhaps a better way would be to ask the ones paying for "Sponsored links" to tell Google to learn how to correctly handle spam. Just my feeble two cents, RKArticle: 148909
On Sep 10, 1:11=A0am, rickman <gnu...@gmail.com> wrote: > Assuming the PSOC3/5 ever actually comes on the market, should we > consider these to be embedded processors with on board FPGA et. al. or > should we think of them as FPGAs with an on board, hard ARM CM3, et. > al.? > > I guess I'm wondering if they will be discussed here much. > > Rick First, they have to become 'real' :) You could include the Actel Fusion in the same space ? The PSCOx logic is at the base-end, so they are Logic Augmented processors, not processor augmented logic. I actually worked up some test designs in PSOC, but we have paused that path until Cypress prove real devices, _and_ sensible prices. (and faster Sw would be nice too...) Meanwhile, Nuvoton have released some 3-5V, low cost M0 core MicroControllers, which expand our options. -jgArticle: 148910
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> I don't know how many of those they still teach. I do believe >> that asynchronous (dual-rail, self-timed logic) is a lost art >> by now. I never got to take the class, but I do remember others >> who did explaining how dual-rail logic works. (snip) >> I have wondered about an FGPA specifically for dual-rail >> asynchronous logic. No useless FF's, and routing optimized >> for dual rail signaling. (snip) > I'm not familiar with dual-rail async logic. What we learned was just > how to implement state machines in async logic which means every state > transition has to be designed and implemented in specific gates so > that the transitions go through a known sequence of meta-states as the > logic changes. At least that is what I recall about it. It was a > looooonnnng time ago and I never used it. Yes, a looonnng time ago, and I didn't even take the class. I just remember discussing it with the people who were taking the class. There are a few sentences in the wikipedia Asynchronous_system page. Every input needs three states, '0', '1', and 'no data'. Similar to the input of an RS flip-flop, there are two lines, one goes active for a '0', the other for a '1', and neither if no data is being sent. Both active is an illegal state. For a given logic block, all the inputs go to either '0' or '1', then wait until the acknowledgement comes back. Then the inputs (I believe at least one, though maybe all) go to the 'no data' state until acknowledge goes away. Inputs need to have three states, otherwise there is no way to know when they are ready. Well, the wikipedia page also describes single rail logic. That seems not to be completely asyncronous, such that only one 'ready' input is used for all the data lines. > I've only seen one async > design that that used a chip (again some thirty years ago) that was > designed to implement async logic. The advantage was it should have > been faster to respond to an input change since it didn't wait for a > clock. > It is a little scary thinking about my early FSM designs. I was > working for some 10 years or more before I learned about meta- > stability. In fact, I worked on a TTL logic design in one of my first > jobs that was not working right because of a problem with unsync'ed > inputs. I don't know that it was a meta-stability issue, but it > likely would have shown up if the more obvious problem wasn't > occurring more often. Military radar jamming equipment IIRC. I > expect it worked well enough to do the job to spec. -- glenArticle: 148911
On Sep 1, 8:52=A0pm, RealInfo <therighti...@gmail.com> wrote: > Hi all > I am a 52 years old electronics technician with massive experience in > analog electronics like audio and power supplies . > > I want to start a career in FPGA designing . > > My intention is to buy a good book and a good FPGA > evaluation board and to do some projects on it to > get experience . > > I did some work in VHDL in the past . > > My question is do I have a real chance to get into this field now > at my age ? FPGA are just another tool in the toolbox, and it is a VERY wide field. If you build into it, by extending what you know already, it should not be too difficult. eg Quite a bit of scope for programmable Logic, in power supply designs. Possible pathways: I see Lattice have a $29 special on their XP2 FPGA board. (Parallel cable) http://www.latticesemi.com/ Or, you could start with simpler CPLD programmable logic via their ispmach4000zepicodevkit - this includes a LCD display, and has a USB link, plus USB parallel path, via a FT2232D. Another training path, is the Cypress PSOC3/5 These are Processor (8051/ARM) plus moderate CPLD fabric, and you can get going for $49. -jgArticle: 148912
> And are those generic design techniques not learned in school? =A0Of > course they are taught. =A0They just don't have specialized courses in > FPGA design because most of these techniques are not unique to FPGAs. > HDL is the only part of FPGA design that is not widely used in other > areas and that is also used, and in fact was invented for, chip > design. Well, that's the point. There was no classes about HDL itself. Yes, there was digital devices class, where students get information about inverters/and/or gates and flip-flops, but not HDL itself, just discrete elements. Someone mentioned here that MSEE could be the way to get deeper, gain more experience and fill up empty knowledge spaces - that is what I want, to have a course of deep analysis of the system, not particularly FPGA or ASIC.Article: 148913
On Sep 9, 7:09=A0pm, Socrates <mail...@gmail.com> wrote: > > And are those generic design techniques not learned in school? =A0Of > > course they are taught. =A0They just don't have specialized courses in > > FPGA design because most of these techniques are not unique to FPGAs. > > HDL is the only part of FPGA design that is not widely used in other > > areas and that is also used, and in fact was invented for, chip > > design. > > Well, that's the point. There was no classes about HDL itself. Yes, > there was digital devices class, where students get information about > inverters/and/or gates and flip-flops, but not HDL itself, just > discrete elements. Someone mentioned here that MSEE could be the way > to get deeper, gain more experience and fill up empty knowledge spaces > - that is what I want, to have a course of deep analysis of the > system, not particularly FPGA or ASIC. Then stick with us kid, stick with us. We'll teach you everything you need to know. Really. Schools don't teach the practical aspects of engineering. They teach the stuff that came from somebody publishing a paper at some point even if it was a hundred years ago. I remember taking Diff Eq which was mostly filled with engineers. About half way through the course someone asked what this stuff was used for. The instructor said he didn't know and didn't care, this was math! Even the engineering schools aren't too far from that. But I will agree, HDL should be taught just like they teach Fortran and assembly language programming... they do still teach those, right? But seriously folks, they do teach programming languages and I think they ought to teach both Verilog and VHDL in undergraduate courses. It might only be a single semester course, but if they did it right, it fo a long way to starting you off on the right foot. Learning to program in HDL is not really the same as wiring gates together. RickArticle: 148914
On Sep 9, 5:46=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Sep 10, 1:11=A0am, rickman <gnu...@gmail.com> wrote: > > > Assuming the PSOC3/5 ever actually comes on the market, should we > > consider these to be embedded processors with on board FPGA et. al. or > > should we think of them as FPGAs with an on board, hard ARM CM3, et. > > al.? > > > I guess I'm wondering if they will be discussed here much. > > > Rick > > First, they have to become 'real' :) > > You could include the Actel Fusion in the same space ? > > The PSCOx logic is at the base-end, so they are Logic Augmented > processors, not processor augmented logic. > > I actually worked up some test designs in PSOC, but we have paused > that path until Cypress prove real devices, _and_ sensible prices. > (and faster Sw would be nice too...) > > =A0Meanwhile, Nuvoton have released some 3-5V, low cost M0 core > MicroControllers, which expand our options. > > -jg Are you the jmg that talks about Nuvoton in the PSOC developer forums? Yeah, I agree that you can't ship vaporware. As to price, what I have seen of the Fusion part, I won't have any sockets that have enough cash for those parts. I seem to recall $40 each. That's twice what I spend on a large MCU and a small FPGA. RickArticle: 148915
On Sep 10, 12:04=A0pm, rickman <gnu...@gmail.com> wrote: > On Sep 9, 5:46=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > > > On Sep 10, 1:11=A0am, rickman <gnu...@gmail.com> wrote: > > > > Assuming the PSOC3/5 ever actually comes on the market, should we > > > consider these to be embedded processors with on board FPGA et. al. o= r > > > should we think of them as FPGAs with an on board, hard ARM CM3, et. > > > al.? > > > > I guess I'm wondering if they will be discussed here much. > > > > Rick > > > First, they have to become 'real' :) > > > You could include the Actel Fusion in the same space ? > > > The PSCOx logic is at the base-end, so they are Logic Augmented > > processors, not processor augmented logic. > > > I actually worked up some test designs in PSOC, but we have paused > > that path until Cypress prove real devices, _and_ sensible prices. > > (and faster Sw would be nice too...) > > > =A0Meanwhile, Nuvoton have released some 3-5V, low cost M0 core > > MicroControllers, which expand our options. > > > -jg > > Are you the jmg that talks about Nuvoton in the PSOC developer > forums? IIRC, jg was taken ;) > Yeah, I agree that you can't ship vaporware. =A0As to price, what I have > seen of the Fusion part, I won't have any sockets that have enough > cash for those parts. =A0I seem to recall $40 each. =A0That's twice what = I > spend on a large MCU and a small FPGA. Yes, but they do show a smaller sibling coming on the road map - which could have a more tolerable price ? -jgArticle: 148916
rickman <gnuarm@gmail.com> wrote: (snip) > Then stick with us kid, stick with us. We'll teach you everything you > need to know. Really. Schools don't teach the practical aspects of > engineering. They teach the stuff that came from somebody publishing > a paper at some point even if it was a hundred years ago. > I remember taking Diff Eq which was mostly filled with engineers. > About half way through the course someone asked what this stuff was > used for. The instructor said he didn't know and didn't care, this > was math! That sounds usual, but you do know that they are used in engineering, even if the instructors didn't. There is always the disconnect between the math department (teaching the math) and the physics department (using it). I have known schools to have a big conference between the two departments, but the problem is always there. Pretty much the same with engineering, though likely more disconnect and less discussion. I do remember my E&M TA noticing the distinction between those who would be theoretical physics, and those who would be engineers or experimental physics. Depending on the problem, one group or the other would do well, but often not both. I also remember a physics quiz needing a solution to a differential equation the day before we learned how to solve it in math class. Off by that much. > Even the engineering schools aren't too far from that. > But I will agree, HDL should be taught just like they teach Fortran > and assembly language programming... they do still teach those, > right? But seriously folks, they do teach programming languages and I > think they ought to teach both Verilog and VHDL in undergraduate > courses. It might only be a single semester course, but if they did > it right, it fo a long way to starting you off on the right foot. > Learning to program in HDL is not really the same as wiring gates > together. They might not get very far, but that is all one should need. Then get a book and start writing. -- glenArticle: 148917
Avnet is currently shipping a Spartan-6/PSoC3 development board. The PSoC 3 is used for several system management functions -- enabling regulators, programmable clock to the FPGA, USB/UART bridge, slave serial configuration of the FPGA, Flash programming, touch-sensitive buttons, driving an LCD, dynamically measuring the voltage/current/ power on three supply rails, I2C interface to a fuel gauge. None of these functions were done explicitly in the programmable logic. The processor peripherals themselves are highly configurable, with a mix of digital and analog capabilities. This board uses engineering sample part CY8C3866AXI-040ES2, which shows as in stock at the Cypress store -- http://www.cypress.com/?mpn=3DCY8= C3866AXI-040ES2. I believe the errata affecting this ES2 device are posted publicly. I'm told that production on this device is imminent. www.em.avnet.com/spartan6lx16-evl Regards, Bryan Avnet On Sep 9, 10:26=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Sep 10, 12:04=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > On Sep 9, 5:46=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > > On Sep 10, 1:11=A0am, rickman <gnu...@gmail.com> wrote: > > > > > Assuming the PSOC3/5 ever actually comes on the market, should we > > > > consider these to be embedded processors with on board FPGA et. al.= or > > > > should we think of them as FPGAs with an on board, hard ARM CM3, et= . > > > > al.? > > > > > I guess I'm wondering if they will be discussed here much. > > > > > Rick > > > > First, they have to become 'real' :) > > > > You could include the Actel Fusion in the same space ? > > > > The PSCOx logic is at the base-end, so they are Logic Augmented > > > processors, not processor augmented logic. > > > > I actually worked up some test designs in PSOC, but we have paused > > > that path until Cypress prove real devices, _and_ sensible prices. > > > (and faster Sw would be nice too...) > > > > =A0Meanwhile, Nuvoton have released some 3-5V, low cost M0 core > > > MicroControllers, which expand our options. > > > > -jg > > > Are you the jmg that talks about Nuvoton in the PSOC developer > > forums? > > IIRC, jg was taken ;) > > > Yeah, I agree that you can't ship vaporware. =A0As to price, what I hav= e > > seen of the Fusion part, I won't have any sockets that have enough > > cash for those parts. =A0I seem to recall $40 each. =A0That's twice wha= t I > > spend on a large MCU and a small FPGA. > > Yes, but they do show a smaller sibling coming on the road map - which > could have a more tolerable price ? > > -jgArticle: 148918
Hi all, I=B4m new to FPGA world too and just buy xilinx SP605, RF (SDR) are my target, know there long way learning but like to learn. there any place where start reading about?? any tips?? for now will start with USRP from gnu radio, my first plan is to port the USRP2 code to the SP605 and design(OpenHardware) a FMC card with the ADC/DAC and RF front end. any help will good, Thanks, C.VArticle: 148919
On 9 Sep., 01:51, Tim Wescott <t...@seemywebsite.com> wrote: > Thanks Ed -- that appears to do what I need. > > Now if I can just get the _rest_ of it to work, I'll be fine! Just select the "Remaining Project Functionality Block 12.1.4" from coregen and choose the required settings. I do not know if Spartan-3A is supported for that core... ;-) KoljaArticle: 148920
On Sep 9, 11:01=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip) > > > Then stick with us kid, stick with us. =A0We'll teach you everything yo= u > > need to know. =A0Really. =A0Schools don't teach the practical aspects o= f > > engineering. =A0They teach the stuff that came from somebody publishing > > a paper at some point even if it was a hundred years ago. > > I remember taking Diff Eq which was mostly filled with engineers. > > About half way through the course someone asked what this stuff was > > used for. =A0The instructor said he didn't know and didn't care, this > > was math! > > That sounds usual, but you do know that they are used in > engineering, even if the instructors didn't. In theory, yes. But we have other ways of skinning that cat, no? Laplace lets us change the awkward diff eq into much simpler equations. I actually don't recall ever needing to figure out a diff eq using any of the methods from the class. But it is important to understand what they are about. A lot of stuff builds on them. > I do remember my E&M TA noticing the distinction between those > who would be theoretical physics, and those who would be engineers > or experimental physics. =A0Depending on the problem, one group or > the other would do well, but often not both. At UM they had separate classes. There was a two semester physics sequence for Chem majors, a three semester sequence for engineers and a four semester sequence for the physics majors. I expect there was a one semester race through for some other majors but I don't recall. I was a chem major and took the engineering sequence just for fun... and was covering my bases in case I switched. In the end, I got the BS in Chem and went back for a MSEE. > > Even the engineering schools aren't too far from that. > > But I will agree, HDL should be taught just like they teach Fortran > > and assembly language programming... they do still teach those, > > right? =A0But seriously folks, they do teach programming languages and = I > > think they ought to teach both Verilog and VHDL in undergraduate > > courses. =A0It might only be a single semester course, but if they did > > it right, it fo a long way to starting you off on the right foot. > > Learning to program in HDL is not really the same as wiring gates > > together. > > They might not get very far, but that is all one should need. > Then get a book and start writing. I have found there is a lot to HDL that isn't really explained fully in books. At least I've never seen it all in one book. But then I guess that stuff wouldn't be covered in a class either. That is the stuff I would need to learn if I ever switch to Verilog. RickArticle: 148921
On Sep 9, 11:24=A0pm, Bryan <bryan.fletc...@avnet.com> wrote: > Avnet is currently shipping a Spartan-6/PSoC3 development board. =A0The > PSoC 3 is used for several system management functions -- enabling > regulators, programmable clock to the FPGA, USB/UART bridge, slave > serial configuration of the FPGA, Flash programming, touch-sensitive > buttons, driving an LCD, dynamically measuring the voltage/current/ > power on three supply rails, I2C interface to a fuel gauge. =A0None of > these functions were done explicitly in the programmable logic. =A0The > processor peripherals themselves are highly configurable, with a mix > of digital and analog capabilities. > > This board uses engineering sample part CY8C3866AXI-040ES2, which > shows as in stock at the Cypress store --http://www.cypress.com/?mpn=3DCY= 8C3866AXI-040ES2. > I believe the errata affecting this ES2 device are posted publicly. > I'm told that production on this device is imminent. > > www.em.avnet.com/spartan6lx16-evl > > Regards, > Bryan > Avnet That seems rather bizarre. These boards are done in conjunction with the chip vendors, no? I would expect Xilinx to never want to be part of the same promotion as a Cypress PSOC. That wouldn't be a lot different from sharing a board with Altera or better, an Actel Fusion part! I didn't know the PSOC had digital interfaces other than one used to boot the chip, I2C I seem to recall. The others are all done in the programmable digital section I thought. What sort of programmable clock to the FPGA? I don't recall seeing a decent PLL on the PSOC. I guess they can take the main clock and divide it down in a counter. But that would be pretty lame. If I need to generate clock rates to the FPGA, I would want more than one and each one to come from a PLL. But even the real FPGAs don't have "real" PLLs that can work with a wide range of input and output clock rates. Cypress makes some clock chips that do that much better, but I guess that technology is just not compatible with FPGA processes. The clock I would really like to see on the PSOC is one that will let a 32.768 kHz, low power osc set the rate for the very low power (< 2 uW) battery backed up RTC and also serve as reference for the PLL to generate the main clocks. I've seen that on just one or two MCUs to date. An older Atmel ARM MCU even had special I/O to put the system into low power mode, not just the MCU and be taken back out. That was a real, real time clock! RickArticle: 148922
> AFAIK the timing constraints may be the biggest issue besides whether > the core works correct. You should be okay if you make sure the input > and output flipflops are inside the IOBs. You can force the latter > with timing constraints and check it using the floorplanner on the > routed design. The problem with the PCI interface is that you can't run all the IOs synchronously. From memory FRAME, TRDY, IRDY and STOP have to be treated combinatorially at the top level. Nial.Article: 148923
On 09/09/10 18:00, glen herrmannsfeldt wrote: <snip> > I have wondered about an FGPA specifically for dual-rail > asynchronous logic. No useless FF's, and routing optimized > for dual rail signaling. These parts are sold as high speed '1.5GHz', may be targeted by synchronous designs, but are asynchronous internally: http://achronix.com/technology.html Detailed technical info seems hard to come by, but this seemed a reasonable read: http://www.en-genius.net/site/zones/programmablelogicZONE/product_reviews/plp_121508 Jan Coombs -- (remove all x from email)Article: 148924
FWIW, I got the answer to this problem from Xilinx support. the pin in question, AB37, is multi-region clock capable (MRCC), however it is located on an outer I/O column, not inner. The description of MRCC pins in the package User Guide includes a note that says only clock capable (CC) pins in the inner I/O column can connect to a BUFG or MMCM. This particular pin can only connect to regional clock resources: BUFIO, BUFR, etc. --steve "Steve Ravet" <steve.ravet@arm.com> wrote in message news:i68oh1$56h$1@cam-news1.cambridge.arm.com... :I am using ISE 12.2 and targeting virtex6 LX760. When I take the netlist : through map I get the following error: : : ERROR:Place:1153 - A clock IOB / BUFGCTRL clock component pair have been : found : that are not placed at an optimal clock IOB / BUFGCTRL site pair. The : clock : IOB component <SWCLKTCK> is placed at site <IOB_X0Y179>. The : corresponding : BUFGCTRL component <SWCLKTCK_ibuf> is placed at site <BUFGCTRL_X0Y2>. The : clock IO can use the fast path between the IOB and the Clock Buffer if a) : the : IOB is placed on a Global Clock Capable IOB site that has the fastest : dedicated path to all BUFGCTRL sites, or b) the IOB is placed on a Local : Clock Capable IOB site that has dedicated fast path to BUFGCTRL sites in : its : half of the device (TOP or BOTTOM). You may want to analyze why this : problem : exists and correct it. If this sub optimal condition is acceptable for : this : design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file : to : demote this message to a WARNING and allow your design to continue. : However, : the use of this override is highly discouraged as it may lead to very : poor : timing results. It is recommended that this error condition be corrected : in : the design. A list of all the COMP.PINs used in this clock placement rule : is : listed below. These examples can be used directly in the .ucf file to : override this clock rule. : < NET "SWCLKTCK" CLOCK_DEDICATED_ROUTE = FALSE; > : : The clock net is assigned to pin AB37 via a LOC constraint in the .ncf file. : This corresponds to IOB_X0Y179 listed, which according to the package docs : is multi-region clock capable. There is no LOC for the BUFGCTRL, it was : inserted by the synthesis tool. So apparently the mapper selected the bad : location. I have a webcase open with xilinx on that question. : : The workaround would seem to be to assign the BUFG to a compatible location, : but which ones are? In FPGA editor I have created nets from AB37 to BUFGs : in all four groups. It routed all of them, including to the one the mapper : complains about, but the nets all have 3-4ns of delay so I think they're on : general routing resources not clock nets. : : I pulled up a different design with properly routed clock nets to compare : but I don't know enough about the internals to see the difference between : them. : : So, in FPGA editor is there a way to restrict the routing of a net to only : be on clock nets? Is there a quicker way of finding out which IOBs and : BUFGs share fast paths? : : thanks, : --steve : :
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