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
Weng Tianxiang <wtxwtx@gmail.com> wrote: ... > That also means that the Digilent cable doesn't support Xilinx > Chipscope, > or the EDK debugger. " It is impossible for an external provider to support Chipscope, as Xilinx doesn't publish the software interface specifications. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 138576
'use_real_email' wrote: > Does anyone have an idea or where i can find information on how can to > implement a cordic algorithm on an altera cyclone II or cyclone III > fpga? > > I would try (in order) 1. the megawizard 2. Ray Andraka's website http://www.andraka.com/cordic.htm 3. the book "DSP Using FPGAs" by Uwe Mayer-Baese regards Alan -- Alan Fitch apfitch at ieee dot orgArticle: 138577
google "cordic" 'use_real_email' wrote: > Does anyone have an idea or where i can find information on how can to > implement a cordic algorithm on an altera cyclone II or cyclone III > fpga? > >Article: 138578
Why is xilinx-microblaze interrupt controller foolishly complicated?Article: 138579
On Feb 28, 4:31=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > Weng Tianxiang <wtx...@gmail.com> wrote: > > ... > > > That also means that the Digilent cable doesn't support Xilinx > > Chipscope, > > or the EDK debugger. " > > It is impossible for an external provider to support Chipscope, as Xilinx > doesn't publish the software interface specifications. > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Hi Uwe, I think It is not the software interface specifications, but the hardware interface specifications. With same hardware interface specifications, Xilinx software can run without any doubt on third party provider products. I think Xilinx adds some hidden hardware interfaces not publicly available to prevent other third party products from running on their ChipScope. For programming purpose, JTAG is an industry standard so that it is easier to write an software to do programming. WengArticle: 138580
Weng Tianxiang <wtxwtx@gmail.com> wrote: > On Feb 28, 4:31 am, Uwe Bonnes <b...@elektron.ikp.physik.tu- > darmstadt.de> wrote: ... > > It is impossible for an external provider to support Chipscope, as Xilinx > > doesn't publish the software interface specifications. > Hi Uwe, > I think It is not the software interface specifications, but the > hardware interface specifications. The hardware is for the Xilinx programmers is published for DLC5 and at least partial reversed engineered for the USB cables. There is even second source firmware to use the USB programmers for some purpose. http://www.ixo.de/info/usb_jtag/ > With same hardware interface specifications, Xilinx software can run > without any doubt on third party provider products. > I think Xilinx adds some hidden hardware interfaces not publicly > available to prevent other third party products from running on their > ChipScope. Mainly Xilinx prevents customers from running Chipscope on Xilinx parts when used with another programming interface. > For programming purpose, JTAG is an industry standard so that it is > easier to write an software to do programming. Look at xc3sprog at sourceforge -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 138581
On 2=BF=F93=C0=CF, =BF=C0=C0=FC1=BD=C315=BA=D0, "H. Peter Anvin" <h...@zyto= r.com> wrote: > LittleAlex wrote: > > > Get a used one on eBay, of buy one OEM from the same place Altera > > does. > > Also, Terasic has a clone of the USB Blaster for $50: > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=3DEnglish&Ca..= . > > -hpa You can buy byteblaster II clone cable at http://fpgaguy.110mb.com/ It is only US $24.95Article: 138582
On 2=D4=C228=C8=D5, =C9=CF=CE=E712=CA=B105=B7=D6, LittleAlex <alex.lo...@em= ail.com> wrote: > On Feb 26, 6:16 pm, "murl...@gmail.com" <murl...@gmail.com> wrote: > > > Inside dma_ddr2_if.v,i noticed the bottom 5 lsb all zero of > > ingress_start_addr/egress_start_addr[27:6] . > > > Why? is it PCIE or DDR2 requirement? > > > How should i provide DDR2 address? > > Read this: <http://www.xilinx.com/support/documentation/ > application_notes/xapp859.pdf> > > It is explained in there. > > AL Yes,but i cann't understand. can you explain?Article: 138583
On Feb 27, 10:54 pm, Allan Herriman <allanherri...@hotmail.com> wrote: > rickman <gnu...@gmail.com> wrote innews:62bd320f-8525-4302-8dd8-d9cf13545e3c@s20g2000yqh.googlegroups.com: > > > > > On Feb 27, 12:18 pm, Allan Herriman <allanherri...@hotmail.com> wrote: > >> rickman <gnu...@gmail.com> wrote > >> innews:55de02a8-97df-4a69-8ec4-9546dcac2 > > 4...@r34g2000vbp.googlegroups.com: > > >> > On Feb 27, 1:58 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > >> >> rickman wrote: > >> >> > When you refer to "high end" processors, you are talking about a > >> >> > literal handful of devices compared to the hundreds or thousands > >> >> > of types of CPUs that are used in embedded systems. If you are > >> >> > talking > > >> >> I'm referring to chips like Intel atom, new PowerQuicc IIP/III > >> >> processors etc. They usually have few PCIe ports as a default and > >> >> if they are not enough a switch is needed. And I don't see why > >> >> low end would not adopt PCIe. Each saved pin helps to get into a > >> >> smaller and cheaper package (altough wirebond and PCIe frequencies > >> >> might be challenging). > > >> > Yes, I know which chips you are referring to. On a few high end > >> > chip > > s > >> > (very high end) you are supporting the idea of utilizing the few > >> > PCIe interfaces rather than using a small number of GPIO pins. > > >> I predict that within a couple of years, many of the smallest (new) > >> processors big enough to be able to run Vxworks or Linux will have at > >> least a couple of lanes of PCIe. If we were back in the 1980s > >> designin > > g > >> with 8051s, these new processors would seem very powerful, but they > >> will be regarded as low end by the time I'm using them. > > > That may be true to some extent, but let's face it, even in five > > years, these very high end embedded processors, which are really > > embedded PCs, will still be the minority of the applications for > > embedded processors and likely an even smaller percentage of the > > controller for embedded FPGAs. There is no need for that level of > > power in most apps, for example the retail routers that are powered by > > ARM7 or ARM9 CPUs or the various processors in all sorts of handheld > > devices that don't need to run WinCE or even WinXP. So the need is > > just not there and is likely to not be there for some time to come. > > >> If you want to use GPIO to configure that FPGA, you'll need a PCIe to > >> GPIO bridge, wasting both a PCIe channel and and a bridge / GPIO > >> chip. (I'm only half joking here.) > > > No, for the vast majority of apps, you are totally joking... or at > > least exaggerating. PCIe is hardly ever the only means of comms other > > than in embedded PC chips perhaps. > > >> Earlier in the thread I used the Intel Atom as an example. That > >> processor & US15W support chip are aimed at netbooks, hence the lack > >> of I/O other than USB and PCIe (mostly). > > > Exactly! It is a two chip set aimed at an app where an FPGA has no > > place. > > >> These sort of architectures started to appear in embedded systems a > >> couple of years ago. Soon they will be pervasive, except in the > >> batter > > y > >> powered market (assuming that PCIe doesn't grow some sort of dynamic > >> power down capability). > > > You mean they have appeared in embedded PCs. That is a very different > > animal from embedded systems where the CPU is designed in rather than > > a CPU board being designed in. > > >> There will still be 8051s and PICs but that's not what this thread's > >> about. > > > No, it is about configuring FPGAs. > > >> > That is a > >> > tradeoff with those chips. But you are asking everyone buying > >> > FPGAs to pay for the Silicon to implement the hard PCIe interface > > >> We're already paying for that in the newer families, e.g. V6. > > >> > and make it part of the configuration logic. > > >> This would be tiny compared to the PCIe end point logic that they > >> already have in there. > > >> (And is "you pay for the programmable routing; the logic is free" > >> still valid?) > > > If you are in marketing, it is true. The rest of us have to pay hard > > cash. Silicon costs cash even if it is vanishingly small, there are > > still all the support costs. It will be added when it sells chips... > > and not before! There are two ways PCIe configuration can sell > > chips. One is if there are applications where the FPGA can't be used > > without this feature. That is a very, very small set of apps. The > > other is if the competition is selling chips with a useful feature > > that you don't have. When this happens, they will all start selling > > it. Just like Lattice selling low cost chips with SERDES functions. > > Now X and A are coming out with that too. But until that happened, it > > didn't cost X or A anything to not be selling that. > > >> > On top of that, I am still not > >> > convinced that this can be done without some data in Flash which > >> > someone else pointed out is required for initilization of the PCI > >> > interface. Is this not the same with PCIe? > > >> A general purpose bridge will need some sort of configuration device. > >> There is nothing saying this has to apply to a specific PCIe > >> bridge, or that any variable part of the configuration has to be > >> stored in Flash or EEPROM. > > > Even the FPGA has to have various parameters preset, no? > > >> We already select the type of configuration with "mode" pins on the > >> FPGA. I'd be quite prepared to waste an additional 3 or 4 pins on a > >> 1000 to 1500 pin device to select one of several different pre-canned > >> PCI configurations. The tradeoffs would be different for smaller > >> packages, but I'm not using those. > > > What about a 256 pin device? You are talking about having to give up > > 4 pins on the processor as being trouble, why are pins so free on an > > FPGA? Besides, why would it be 3 or 4? Just what information has to > > be set in order for the FPGA to respond on a PCIe port? > > >> >> > about adding a "switch" then you are adding an extra chip and > >> >> > you can just as easily add any sort of chip to facilitate > >> >> > booting the FPGA. > > >> >> The problem is that there are only few vendors for special bridge > >> >> chips to GPIO etc. But for PCIe switches there are many vendors > >> >> even some with identical pinouts. That helps multisourcing for > >> >> manufacturing. Also Industrial temperature requirements narrow > >> >> down the choices. > > >> > You are dwelling on PCIe and I am not. There are many ways to skin > >> > a cat and most do not require anything special in the FPGA. Look > >> > at what I wrote without assuming this is using PCIe. > > >> I'm the OP, which makes me the one dwelling on PCIe :) Besides, it's > >> i > > n > >> the thread title. > > > You are missing my point. By "dwelling" I meant you are so focused on > > the PCIe that you missed my point. You don't *need* PCIe to configure > > an FPGA. It is more complex, higher cost and uses more I/Os on both > > the CPU and the FPGA in the vast majority of designs. ***THAT*** is > > the main point. The other options are just better in all respects for > > 99.9% of current and 95% of foreseeable apps. The Atoms of the world > > are far in the minority. > > Rick, I think you're the one missing the point. I think those (obviously > fabricated) stats relate to your personal experience and don't > neccessarily apply to all applications. *My* personal experience is that > 100% of systems that *I design* would be made smaller and cheaper if > FPGAs could configure over PCIe. I know that you think I am missing the point. That is what is not happening here, communication. I feel I am explaining myself well and you seem to feel I am being absurd. But your responses are not any less absurd. In fact, the above response seems to be trying to parrot my comments, so clearly if you feel my responses are absurd, then yours must be as well. > I'm well aware that I'm probably in the minority of designers here. But > that isn't to say that the issues I face in design are not important. The issue isn't with the number of designers, it is about the number and profitability of the designs. The FPGA companies can't make money adding every bell and whistle we all would like. PCIe may become a defacto standard on many more processors in the future. But until that is clear, I wouldn't expect X, A or L to worry about adding a boot capability via PCIe. > You employ logical fallacies in your arguments. E.g. I used an example > of a 1000 to 1500 pin FPGA. You reply to my statement by implying that > it doesn't work for a 256 pin FPGA. Well, I already knew that, which is > why I qualified my statement with the size of the FPGA in the first > place. I just don't know how to respond to bad arguments like that > except in an emotive way, and as a result I'm stopping posting (since caf > is a civilised place). You consider my responses illogical. The example you give is not a "logical" argument, it is illustrative. For every 1000 to 1500 pin FPGA sold, there are likely hundreds if not thousands of 256 pin FPGAs with a significantly larger total profit. That is what the entire issue is about, whether or not the FPGA makers will find it profitable to invest time, resources, money and the *extremely* valuable product Silicon in a feature that will be used by a small fraction of the end users, and even then is a show stopper (preventing them from using an FPGA) for nearly none of them. Hey! I have been looking... no BEGGING the FPGA companies to make more FPGAs available in smaller packages (meaning low pin count and correspondingly low price) to no avail. The most recent families from the vendors I have seen are even dropping support for the smaller packages that I am currently using. They don't really care because it just is not profitable for them to provide what I need (or at least that is what they think). You can choose to be blind to the realities of chip and board design, but if you discuss them here, please don't expect me to also be as blind. I hope this was a civilized enough response. RickArticle: 138584
I hope that CPLDs are okay to talk about on this FPGA newsgroup. I'm just starting out with CPLDs, I've ordered some XC9536 chips and am trying to do some simple test projects with Xilinx's ICE program. And I am getting frustrated with it. I move a part, and it throws errors (and disconnects wires from the parts i just moved, so all in all, very irritating) I wish I could find a simple, yet free graphical CPLD development program, since right now, I don't know enough about any HDL language (VHDL/Verilog HDL) yet. Any help would be most appreciated. I already know that I can build my own programming cable, that's no issue. The entering of the code is what is giving me issues.Article: 138585
Hi the time goes faster and faster each month :( so there is less time to write magazine content still the february issue is released with less delay then last few issue http://groups.google.com/group/antti-brain/files?hl=en AnttiArticle: 138586
On Sun, 1 Mar 2009 02:38:41 -0600, "dracosilv" <dracosilver@wi.rr.com> wrote: >I hope that CPLDs are okay to talk about on this FPGA newsgroup. I'm just >starting out with CPLDs, I've ordered some XC9536 chips and am trying to do >some simple test projects with Xilinx's ICE program. And I am getting >frustrated with it. I move a part, and it throws errors (and disconnects >wires from the parts i just moved, so all in all, very irritating) If you don't define which device pins are associated with what functions, the fitter is free to move things around as it see fit (no pun intended (really!)). When you have decided on a mapping of pins to functions, you use a UCF (user constraint file) to lock them in place. All arbitrary mappings of pins to functions will not be possible, due to limitations just what resources are available in a particular CPLD. A reasonable approach is to first setup a UCF with only your timing constraints, fit that, and see how well it matches up with what you want for the physical layout, then modify as necessary. Look under Help | CPLD Design | Constraints. -- Rich Webb Norfolk, VAArticle: 138587
Rich Webb wrote: > On Sun, 1 Mar 2009 02:38:41 -0600, "dracosilv" <dracosilver@wi.rr.com> > wrote: > >> I hope that CPLDs are okay to talk about on this FPGA newsgroup. >> I'm just starting out with CPLDs, I've ordered some XC9536 chips and >> am trying to do some simple test projects with Xilinx's ICE program. >> And I am getting frustrated with it. I move a part, and it throws >> errors (and disconnects wires from the parts i just moved, so all in >> all, very irritating) > > If you don't define which device pins are associated with what > functions, the fitter is free to move things around as it see fit (no > pun intended (really!)). > > When you have decided on a mapping of pins to functions, you use a UCF > (user constraint file) to lock them in place. > > All arbitrary mappings of pins to functions will not be possible, due > to limitations just what resources are available in a particular > CPLD. A reasonable approach is to first setup a UCF with only your > timing constraints, fit that, and see how well it matches up with > what you want for the physical layout, then modify as necessary. > > Look under Help | CPLD Design | Constraints. I think that I might have not defined the word 'pins' properly in my case. I'm referring to the diagram on screen (the graphical layout) I move one of those devices around, and the program breaks the connections that I have made to the bits of logic (tristate buffers, and gates, etc). That's what my issue is.Article: 138588
On Mar 1, 8:42=A0pm, "dracosilv" <dracosil...@wi.rr.com> wrote: > Rich Webb wrote: > > On Sun, 1 Mar 2009 02:38:41 -0600, "dracosilv" <dracosil...@wi.rr.com> > > wrote: > > >> I hope that CPLDs are okay to talk about on this FPGA newsgroup. > >> I'm just starting out with CPLDs, I've ordered some XC9536 chips and > >> am trying to do some simple test projects with Xilinx's ICE program. > >> And I am getting frustrated with it. =A0I move a part, and it throws > >> errors (and disconnects wires from the parts i just moved, so all in > >> all, very irritating) > > > If you don't define which device pins are associated with what > > functions, the fitter is free to move things around as it see fit (no > > pun intended (really!)). > > > When you have decided on a mapping of pins to functions, you use a UCF > > (user constraint file) to lock them in place. > > > All arbitrary mappings of pins to functions will not be possible, due > > to limitations just what resources are available in a particular > > CPLD. A reasonable approach is to first setup a UCF with only your > > timing constraints, fit that, and see how well it matches up with > > what you want for the physical layout, then modify as necessary. > > > Look under Help | CPLD Design | Constraints. > > I think that I might have not defined the word 'pins' properly in my case= . > I'm referring to the diagram on screen (the graphical layout) =A0I move o= ne of > those devices around, and the program breaks the connections that I have > made to the bits of logic (tristate buffers, and gates, etc). =A0That's w= hat > my issue is. ISE schematic is really not made to be used. with some effort you can get something done with it but it is really not meant to be a design entry method AnttiArticle: 138589
Antti.Lukats@googlemail.com wrote: > On Mar 1, 8:42 pm, "dracosilv" <dracosil...@wi.rr.com> wrote: [SNIPPED BECAUSE OF STUPID AIOE NOT LETTING ME QUOTE LOTS OF LINES] >> >> I think that I might have not defined the word 'pins' properly in my >> case. I'm referring to the diagram on screen (the graphical layout) >> I move one of those devices around, and the program breaks the >> connections that I have made to the bits of logic (tristate buffers, >> and gates, etc). That's what my issue is. > > ISE schematic is really not made to be used. > > with some effort you can get something done with it > but it is really not meant to be a design entry method > > Antti Any good suggestion for a schematic editor that *CAN* be acutally used?Article: 138590
dracosilv wrote: > Rich Webb wrote: > >>On Sun, 1 Mar 2009 02:38:41 -0600, "dracosilv" <dracosilver@wi.rr.com> >>wrote: >> >> >>>I hope that CPLDs are okay to talk about on this FPGA newsgroup. >>>I'm just starting out with CPLDs, I've ordered some XC9536 chips and >>>am trying to do some simple test projects with Xilinx's ICE program. >>>And I am getting frustrated with it. I move a part, and it throws >>>errors (and disconnects wires from the parts i just moved, so all in >>>all, very irritating) >> >>If you don't define which device pins are associated with what >>functions, the fitter is free to move things around as it see fit (no >>pun intended (really!)). >> >>When you have decided on a mapping of pins to functions, you use a UCF >>(user constraint file) to lock them in place. >> >>All arbitrary mappings of pins to functions will not be possible, due >>to limitations just what resources are available in a particular >>CPLD. A reasonable approach is to first setup a UCF with only your >>timing constraints, fit that, and see how well it matches up with >>what you want for the physical layout, then modify as necessary. >> >>Look under Help | CPLD Design | Constraints. > > > I think that I might have not defined the word 'pins' properly in my case. > I'm referring to the diagram on screen (the graphical layout) I move one of > those devices around, and the program breaks the connections that I have > made to the bits of logic (tristate buffers, and gates, etc). That's what > my issue is. > > The schematic editor has it good points and its bad points. First of all, your problem is easy to take care of. On the right hand side of the screen, under the file list part, there is a choice under a section labelled: "when you move an object" of either "keep the connections to other objects" or "break the connections to other objects." That will fix this issue. However, moving things in the editor is not easy to do quickly and it is hard to keep neat schematics as a project grows. It is particularly annoying when you move something to another sheet. If you use paste, special, then you can keep the pin names but they will be invisible so you have to rename them to make them visible. Most people here do not use schematics. Using VHDL or verilog gives them the opportunity to come here and ask how to trick the system into doing what they want. Getting brams is always fun. With schematics you miss most of that since, if you want a bram, you just put one in.Article: 138591
dracosilv wrote: > Antti.Lukats@googlemail.com wrote: > >>On Mar 1, 8:42 pm, "dracosilv" <dracosil...@wi.rr.com> wrote: > > [SNIPPED BECAUSE OF STUPID AIOE NOT LETTING ME QUOTE LOTS OF LINES] > >>>I think that I might have not defined the word 'pins' properly in my >>>case. I'm referring to the diagram on screen (the graphical layout) >>>I move one of those devices around, and the program breaks the >>>connections that I have made to the bits of logic (tristate buffers, >>>and gates, etc). That's what my issue is. >> >>ISE schematic is really not made to be used. >> >>with some effort you can get something done with it >>but it is really not meant to be a design entry method >> >>Antti > > > Any good suggestion for a schematic editor that *CAN* be acutally used? > > You will not get much other choice since there are not many to begin with. The tide is going to software since very few people know hardware anymore.Article: 138592
doug wrote: > dracosilv wrote: >> >> I think that I might have not defined the word 'pins' properly in my >> case. I'm referring to the diagram on screen (the graphical layout) >> I move one of those devices around, and the program breaks the >> connections that I have made to the bits of logic (tristate buffers, >> and gates, etc). That's what my issue is. >> >> > The schematic editor has it good points and its bad points. First of > all, your problem is easy to take care of. On the right hand side of > the screen, under the file list part, there is a choice under a > section labelled: "when you move an object" of either "keep the > connections to other objects" or "break the connections to other > objects." That will fix this issue. However, moving things in > the editor is not easy to do quickly and it is hard to keep neat > schematics as a project grows. It is particularly annoying when > you move something to another sheet. If you use paste, special, > then you can keep the pin names but they will be invisible so > you have to rename them to make them visible. > > Most people here do not use schematics. Using VHDL or verilog > gives them the opportunity to come here and ask how to trick > the system into doing what they want. Getting brams is always > fun. With schematics you miss most of that since, if you want > a bram, you just put one in. Forgive me, but what is a bram? As i mentioned earlier, I'm new to the very interesting field of CPLDs/FPGAs.Article: 138593
doug wrote: > dracosilv wrote: >> [SNIPPED BECAUSE OF STUPID AIOE NOT LETTING ME QUOTE LOTS OF LINES] >> >> Any good suggestion for a schematic editor that *CAN* be acutally >> used? >> >> > You will not get much other choice since there are not many > to begin with. The tide is going to software since very few > people know hardware anymore. So I guess that I'm stuck using a HDL then? Well that sucks.Article: 138594
dracosilv wrote: > doug wrote: > >>dracosilv wrote: >> >>>I think that I might have not defined the word 'pins' properly in my >>>case. I'm referring to the diagram on screen (the graphical layout) >>>I move one of those devices around, and the program breaks the >>>connections that I have made to the bits of logic (tristate buffers, >>>and gates, etc). That's what my issue is. >>> >>> >> >>The schematic editor has it good points and its bad points. First of >>all, your problem is easy to take care of. On the right hand side of >>the screen, under the file list part, there is a choice under a >>section labelled: "when you move an object" of either "keep the >>connections to other objects" or "break the connections to other >>objects." That will fix this issue. However, moving things in >>the editor is not easy to do quickly and it is hard to keep neat >>schematics as a project grows. It is particularly annoying when >>you move something to another sheet. If you use paste, special, >>then you can keep the pin names but they will be invisible so >>you have to rename them to make them visible. >> >>Most people here do not use schematics. Using VHDL or verilog >>gives them the opportunity to come here and ask how to trick >>the system into doing what they want. Getting brams is always >>fun. With schematics you miss most of that since, if you want >>a bram, you just put one in. > > > Forgive me, but what is a bram? As i mentioned earlier, I'm new to the very > interesting field of CPLDs/FPGAs. A bram is a blockram. That is a memory block that is available in some Xilinx fpgas. Not in cplds though. > >Article: 138595
On Mar 1, 9:51=A0pm, doug <x...@xx.com> wrote: > dracosilv wrote: > > doug wrote: > > >>dracosilv wrote: > > >>>I think that I might have not defined the word 'pins' properly in my > >>>case. I'm referring to the diagram on screen (the graphical layout) > >>>I move one of those devices around, and the program breaks the > >>>connections that I have made to the bits of logic (tristate buffers, > >>>and gates, etc). =A0That's what my issue is. > > >>The schematic editor has it good points and its bad points. First of > >>all, your problem is easy to take care of. =A0On the right hand side of > >>the screen, under the file list part, there is a choice under a > >>section labelled: "when you move an object" of either "keep the > >>connections to other objects" or "break the connections to other > >>objects." =A0That will fix this issue. =A0However, moving things in > >>the editor is not easy to do quickly and it is hard to keep neat > >>schematics as a project grows. It is particularly annoying when > >>you move something to another sheet. If you use paste, special, > >>then you can keep the pin names but they will be invisible so > >>you have to rename them to make them visible. > > >>Most people here do not use schematics. Using VHDL or verilog > >>gives them the opportunity to come here and ask how to trick > >>the system into doing what they want. =A0Getting brams is always > >>fun. With schematics you miss most of that since, if you want > >>a bram, you just put one in. > > > Forgive me, but what is a bram? =A0As i mentioned earlier, I'm new to t= he very > > interesting field of CPLDs/FPGAs. > > A bram is a blockram. =A0That is a memory block that is available > in some Xilinx fpgas. =A0Not in cplds though. > > Lattice has/had some CPLDs with BRAM too but in generic, yes the classical CPLDs dont have block rams AnttiArticle: 138596
dracosilv wrote: > doug wrote: > >>dracosilv wrote: >> >>>[SNIPPED BECAUSE OF STUPID AIOE NOT LETTING ME QUOTE LOTS OF LINES] >>> >>>Any good suggestion for a schematic editor that *CAN* be acutally >>>used? >>> >>> >> >>You will not get much other choice since there are not many >>to begin with. The tide is going to software since very few >>people know hardware anymore. > > > So I guess that I'm stuck using a HDL then? That depends. I still like schematics as it is far easier to see the flow. Components under the main schematic are in VHDL when it is a better choice. If there is a lot of connectivity, schematics are far easier to understand. Chasing things around in a text editor is always a real pain. I am visually oriented and I like to follow the flow. However, things heavily logic oriented are sometimes easier for me to put in VHDL. Big multiplexers are another. In the end, the code is about half and half. One argument is that HDLs are more portable and that is true but it is of more importance to people who move between chips more often. I have been using Xilinx chips since 1991 so I am pretty old and slow to change my ways. > > Well that sucks. > >Article: 138597
doug wrote: (snip) > That depends. I still like schematics as it is far easier > to see the flow. Components under the main schematic are > in VHDL when it is a better choice. If there is a lot of > connectivity, schematics are far easier to understand. > Chasing things around in a text editor is always a real > pain. I am visually oriented and I like to follow the > flow. However, things heavily logic oriented are > sometimes easier for me to put in VHDL. Big multiplexers > are another. In the end, the code is about half and half. I think my choice would be to write in verilog, and then use a verilog to schematic conversion program. They aren't perfect, but maybe good enough. If the verilog is appropriately modular, then the schematic for each module isn't too complicated. > One argument is that HDLs are more portable and that is > true but it is of more importance to people who move > between chips more often. I have been using Xilinx chips > since 1991 so I am pretty old and slow to change my ways. Yes, but Xilinx changes the families often enough that it might just as well be different. -- glenArticle: 138598
Glen Herrmannsfeldt wrote: > doug wrote: > (snip) > >> That depends. I still like schematics as it is far easier >> to see the flow. Components under the main schematic are >> in VHDL when it is a better choice. If there is a lot of >> connectivity, schematics are far easier to understand. >> Chasing things around in a text editor is always a real >> pain. I am visually oriented and I like to follow the >> flow. However, things heavily logic oriented are >> sometimes easier for me to put in VHDL. Big multiplexers >> are another. In the end, the code is about half and half. > > > I think my choice would be to write in verilog, and then use > a verilog to schematic conversion program. They aren't > perfect, but maybe good enough. Do you have any good examples. The ISE translations are mostly useless. If the verilog is appropriately > modular, then the schematic for each module isn't too complicated. It is probably easier to have the program make verilog from schematics and then we know the schematics are readable. > >> One argument is that HDLs are more portable and that is >> true but it is of more importance to people who move >> between chips more often. I have been using Xilinx chips >> since 1991 so I am pretty old and slow to change my ways. > > > Yes, but Xilinx changes the families often enough that it > might just as well be different. They also have changed the software a lot. The older software used to require a reboot after a PAR run. If you did not do it yourself, it would blow up for you. The one thing that seems to have gotten worse over the years is the guided routing. In the early 90's, it worked well. The other part that has gotten much worse is the synthesis. They also hired a bunch of programmers who had never used fpgas to develop ISE starting with version 7 and the interface has gotten worse with each version. Well, I do not know about version 8 since there was such a memory leak in the schematic conversion (meaning that their "testing" procedure was the same as Microsoft, meaning that if it compiles it must be correct) that it never would process my schematics. Version 9 would not either since they changed some of the reserved words and gave no way to find that out. > > -- glen >Article: 138599
On Mar 1, 9:38=A0pm, "dracosilv" <dracosil...@wi.rr.com> wrote: > > I wish I could find a simple, yet free graphical CPLD development program= , > since right now, I don't know enough about any HDL language (VHDL/Verilog > HDL) yet. Xilinx tool flows still support ABEL (I think) - that's an intermediate HDL, that is more suited to smaller designs. Lattice also have ABEL, and Atmel have the similar CUPL. Such Boolean Entry languages have a simple, easy to learn syntax : They are also MUCH more stable and portable, than Schematic Entry, but close to the wire-level design model. Reg.ck =3D ClockPin; Reg.D =3D !Reg; Reg.CE =3D EnablePin; Reg2.T =3D Reg1 & Reg0; etc... The fitter reports usually report in Boolean Egn format, and some can switch to VHDL so you can learn from that too. -jg
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