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
My Xilinx EDk (XPS) is not starting. It is giving error: "This application has failed to start because libXdh_Part_Anno.dll was not found. Re-installing the application may fix this problem." I reinstalled, but of no use. Can anyone help ?? Thanks, SatyamArticle: 138876
Hi it has come to my attention that I have commented in Google threads where the original posting was in violation with DMCA. unfortunatly those threads may get archived in the way that it is not clear any more from whom the information is originating. http://groups.google.co.uk/group/comp.arch.fpga/search?hl=en&group=comp.arch.fpga&q=can_tl_bsp&qt_g=Search+this+group the above link as of today returns a thread with 3 posts, and listing me as author? however none of the 3 posts are from me. I think I posted later on that thread, but my posts seem to be removed while my name is still attached to the thread. I herein promise todo all my best not to post on threads where previous postings may violate DMCA or copyrights. And of course I will not make such postings myself as I have not done to my knowledge before either. Antti LukatsArticle: 138877
On Wed, 11 Mar 2009 16:36:44 +0100, Martin Schoeberl wrote: > Hi all, > > looks like opencores.org changes it's hosting strategies without asking > their user and core providers. At the moment the CVS access is down and > it looks like they changed to SVN. Without a notice to the core > providers. > Hi Martin, ORSoC AB, who took over responsibility for OpenCores in late 2007, have reimplemented the entire website back end. The switch over was earlier this week, but I believe has been in planning since the take over. At the same time they have switched to Subversion. The website is mostly back up, and subversion access seems to work. The old mailing lists are now web based forums with email notification. I suggest you try posting there to try to get more information. HTH, JeremyArticle: 138878
Hello, Maybe this is a bit offtopic but may I ask you what kind of I2C ipcore do you use? I have to implement some i2c slave logic with some readable and writable registers in my next design and I'm curious about that.. thank you in advance On Mar 12, 5:05=A0am, Digi Suji <digis...@gmail.com> wrote: > Hi, > > I am trying to read a byte from a particular address in I2C EEPROM. > But the data I get is from a different location. For example, if try > to read data from "x05" location, the byte from "x0B" location is > read. If try to read data from "x06" location, data from "x0D" is > read. If I try to read data from "x07", data from "x0F" is read. If > you notice above situation, a fixed pattern is followed. > > I am using a I2C Master Core controller to read data from I2C EEPROM. > Xilinx Post route simulation works fine but when I try to configure > the Spartan 3E FPGA, I get the above described results. I2C EEPROM is > external to the FPGA and I2C controller goes in to the FPGA. > > I am confused as to why is this happening. Can any one please help. > > Thanks.Article: 138879
The OpenCores team are putting in enormous resources in making sure that the OpenCores will continue to exist/expand. It is important that the platform can continue to support good services to both users and core-providers, also for the next 10-20 years. If possible it is also good if we can provide an even greater =93trust=94 and =93quality=94 i= n the cores at OpenCores. The complete redesign of the OpenCores-platform enable us to support all users with a future-proof and professional site. It also support integrating new functionalities much easier then before, since the old platform had grown out of proportion. We feel that we have listen to the community, since we get allot of Feedback - i.e. complaining about poor statistics, forum structure, etc. But unfortunately we also get some few complaints from a small portion of users that are just against all changes :-( But for those users who has more concrete suggestion/ideas/ improvements, feel free to contact us at oc-team@opencores.org Best regards, The OC-teamArticle: 138880
On 13 Mar, 05:22, Jacko <jackokr...@gmail.com> wrote: > On 12 Mar, 21:44, rickman <gnu...@gmail.com> wrote: > > > On Mar 12, 1:30 pm, Jacko <jackokr...@gmail.com> wrote: > > > > hi > > > > 292 LEs fully stripped, no ROM, no RAM no IO pins, 16 bit address, 16 > > > bit data Bus. Expected 20-30MHz, (36 pins plus power), About 10 MIPS > > > at 20MHz. > > > > cheers jacko > > > What's a MIPS? =A0Native instructions? =A0Or something that can be > > compared to other processors? > > Native instructions. Fetch/execute, and Fetch/execute/execute (SUm > instruction). > > > I have yet found a good way to compare these small, FPGA CPUs. =A0The > > ZPU is pretty small, but the originator seems to still think in terms > > of Dhrystones. =A0I can't begin to measure my processor in Dhrystones. > > I do not yet have any C compilier so drystones are not measurable. > > > The original imnplementation was about 600 LUTs, 50 MHz, 50 MIPS in an > > Altera ACEX 1K part (very old and pretty slow). =A0I am working to > > update it for a more current FPGA. > > A re-implementation of the ALU is possible to improve clock rate, but > the area does increase as it is a 16 bit ALU, with 4 operations. So 4 > ops * 4way multiplex. The reason for using a carry chain is that the > alu shrinks as some of the multiplex is merged with the alu operations > (not much more complicated than just add in luts). I understand from > altera support that the two lut3 arithmetic mode is not really used, > and so fast carry propagation is not done, and it is the critical > path, hence the extra cycle inserted. > > A harvard architecture is not used. Code density is reasonably high > using threaded subroutines, as no jump opcode has to prefix the jump > address. In full ASIC custom logic such carry propergation issues are > not as dominant .So considering each instruction is 16 bit data in > width, the processor is quite impressivly small. If only the carry > chain was used effectively in lut4 mode. > > Of course all optimization was for area, and not speed, with no > retiming. Just the register duplication (2 LEs) for increased > routability. Yes lack of high level software tools is a real pain for > product design. But I'm slowly working on that. I do not have a major > development team. I am just me, and this is not paid work. > > I think my offer of 1 free core per chip, for just a logo print, and > documentation copyright recognition and URL is very good. Especially > as this offer unlike the still standing BSD offer allows derived > products without revealing the derived source. > > Cheers jacko Jacko what you think as "good" is not the same what others think. you !=3D others; if you use BSD license you can not attach it to the FIRST instance of the core inside and asic or fpga, meaning the user is free to use ANY number of copies of the core, your restriction is not valid... as of the logo print, sorry if you do not understand it, even if the core and other copyright restrictions by you may be ok for the legal department of large scale corporation, the logo print will not be... for sure not with that low quality bitmap, and also not when you make better artwork also very unlikely so what you are asking and what you think is good is actually something that will drive any potential users (if there are any) away from using the core. if you want some $$$ then you should offer some commercial licensing, not try get money from paypal donations and indirect advertizement by the logo print of yours... my 3 cents AnttiArticle: 138881
rickman wrote: > > I am still looking for a good small soft-core, and well it seem > > not to exist... > > I seem to recall that you were trying to find a bit serial CPU that > would be the smallest possible in an FPGA. I don't think it is possible to make a serial CPU smaller than a parallel one. Here is a 16 bit CPU with interrupt support built with only 65 flip-flop's. If you reduce the size to 12 bit (3 kbyte memory space) you can even save 12 flip-flop's. http://www.bitlib.de/pub/mproz/mproz3_e.pdf (with internal RAM) http://www.bitlib.de/pub/mproz/mproz2a.pdf (with external RAM) schematics in the zip files: http://www.bitlib.de/pub/mproz/Article: 138882
On 28 Jan, 12:05, Antti <Antti.Luk...@googlemail.com> wrote: > On Jan 27, 9:08=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On Jan 25, 10:34=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > Now when xilinx web is back online, well they do no have not a single > > > reference design for the ethernet usingSFPoptical links > > > all the demos are for the marvell SGMII phy only > > > > i tried to change the TEMAC PHY form SGMII to 1000base-x but > > > unfortunatly the system did not work after that. > > > well all phy registers readback 0, so maybe there is some major > > > problem with some clocking, and there are no other changes > > > required, but i kinda can not belive that xilinx has not ever > > > made abase1000-xbased system for some of their board (ml405/ml505..) > > > > Antti > > > ok, i have a reference design, but our ownSFP/ethernet design still > > doesnt work after MPMC2-MPMC3 migration > > > Antti > > it all works!! > > but we had to decrypt some more xilinx encrypted IP core sources > and change low level settings of the MGT and hard TEMAC > > Antti the decrypted files can be downloaded from Xilinx FTP site ftp://ftp.xilinx.com/pub/swhelp/ip_updates/ar31919_xps_ll_temac_v1_01_b.zip so there is no need to seek other solutions Antti LukatsArticle: 138883
> Jacko > > what you think as "good" is not the same what others think. > > you != others; I never said others may think this is a good offer, just that I think it is a good offer. > if you use BSD license you can not attach it to the FIRST > instance of the core inside and asic or fpga, meaning > the user is free to use ANY number of copies of the > core, your restriction is not valid... If BSD is used then BSD it is, BSD does not prevent me from doing what I want with MY source, and so I am able to offer OTHER licences. The 1 core per chip licence is not BSD, instead I am making another issue of the code under my copyright, in acordance with my wishes. You are correct with respect to the licence used for the BSD issue. But theat issue would not allow using proprietory logic, without that other logic also being made part of the BSD. > as of the logo print, sorry if you do not understand it, > even if the core and other copyright restrictions by > you may be ok for the legal department of large scale > corporation, the logo print will not be... for sure > not with that low quality bitmap, and also not when > you make better artwork also very unlikely What's so difficult about the reproduction of a BW image, also this non BSD licence version did in no way specify the size that the logo had to be printed at. > so what you are asking and what you think is good > is actually something that will drive any potential > users (if there are any) away from using the core. ? > if you want some $$$ then you should offer some > commercial licensing, not try get money from > paypal donations and indirect advertizement > by the logo print of yours... I have not refused any offer of comercial licencing, although I do think that more than 1 core per chip is a little way off. > my 3 cents Fair enough cheers jackoArticle: 138884
On 13 Mar, 13:02, Herbert Kleebauer <k...@unibwm.de> wrote: > rickman wrote: > > > I am still looking for a good small soft-core, and well it seem > > > not to exist... > > > I seem to recall that you were trying to find a bit serial CPU that > > would be the smallest possible in an FPGA. =A0 > > I don't think it is possible to make a serial CPU smaller than > a parallel one. Here is a 16 bit CPU with interrupt support > built with only 65 flip-flop's. If you reduce the size to > 12 bit (3 kbyte memory space) you can even save 12 flip-flop's. > > http://www.bitlib.de/pub/mproz/mproz3_e.pdf=A0(with internal RAM)http://w= ww.bitlib.de/pub/mproz/mproz2a.pdf=A0 =A0(with external RAM) > > schematics in the zip files: > > http://www.bitlib.de/pub/mproz/ Interesting MISC design. Any idea what the LE count is? Extra features offered by nibz. -- predecrement/postincrement -- a logic accumulator -- faster indexing -- subroutine support instructions -- a parameter stack -- a clock counter Features not currently offered by nibz -- interrupt support cheers jackoArticle: 138885
Herbert Kleebauer wrote: > rickman wrote: > > > > I am still looking for a good small soft-core, and well it seem > > > not to exist... > > > > I seem to recall that you were trying to find a bit serial CPU that > > would be the smallest possible in an FPGA. > > I don't think it is possible to make a serial CPU smaller than > a parallel one. Here is a 16 bit CPU with interrupt support > built with only 65 flip-flop's. If you reduce the size to > 12 bit (3 kbyte memory space) you can even save 12 flip-flop's. > > http://www.bitlib.de/pub/mproz/mproz3_e.pdf (with internal RAM) > http://www.bitlib.de/pub/mproz/mproz2a.pdf (with external RAM) > > schematics in the zip files: > > http://www.bitlib.de/pub/mproz/ Serial processors only require a 1 bit alu, registers are shift registers with a single in and out data line. The availability of large lowcost bit serial memories like SD cards opens the possibility of creating a small processor. There may be issues how a serial processor design will map on the current parts but the logic is significantly simpler that an equivalent parallel design. None of this is free. The resulting processor will be slower for the same clock speed. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.comArticle: 138886
On 13 Mar, 13:21, marcus.erlands...@gmail.com wrote: > The OpenCores team are putting in enormous resources in making sure > that > the OpenCores will continue to exist/expand. It is important that the > platform can continue to support good services to both > users and core-providers, also for the next 10-20 years. If possible > it is > also good if we can provide an even greater =93trust=94 and =93quality=94= in > the > cores at OpenCores. > > The complete redesign of the OpenCores-platform enable us to support > all > users with a future-proof and professional site. It also support > integrating > new functionalities much easier then before, since the old > platform had grown out of proportion. > > We feel that we have listen to the community, since we get allot of > Feedback - i.e. complaining about poor statistics, forum structure, > etc. But > unfortunately we also get some few complaints from a small portion of > users > that are just against all changes :-( > > But for those users who has more concrete suggestion/ideas/ > improvements, > feel free to contact us at oc-t...@opencores.org > > Best regards, > > The OC-team it seems that many links are now dead or then project deleted :( too bad AnttiArticle: 138887
On Mar 13, 6:10=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On 13 Mar, 13:21, marcus.erlands...@gmail.com wrote: > > > > > The OpenCores team are putting in enormous resources in making sure > > that > > the OpenCores will continue to exist/expand. It is important that the > > platform can continue to support good services to both > > users and core-providers, also for the next 10-20 years. If possible > > it is > > also good if we can provide an even greater =93trust=94 and =93quality= =94 in > > the > > cores at OpenCores. > > > The complete redesign of the OpenCores-platform enable us to support > > all > > users with a future-proof and professional site. It also support > > integrating > > new functionalities much easier then before, since the old > > platform had grown out of proportion. > > > We feel that we have listen to the community, since we get allot of > > Feedback - i.e. complaining about poor statistics, forum structure, > > etc. But > > unfortunately we also get some few complaints from a small portion of > > users > > that are just against all changes :-( > > > But for those users who has more concrete suggestion/ideas/ > > improvements, > > feel free to contact us at oc-t...@opencores.org > > > Best regards, > > > The OC-team > > it seems that many links are now dead or then project deleted :( > > too bad > > Antti Hi Antti. Actually, there are more project now visible, then before. But some projects where started 2000-2004, but never completed and no one has updated the project ever since. These project will be moved to another category shortly, so that it is clear to all users which project that are ready and not. Send an email to oc-team@opencores.org and let us know what project has been deleted, so that we can double check this. As for the links, we will be fixing allot of the "broken" links within the next coming weeks.. Best regards, The OC-teamArticle: 138888
On Mar 6, 5:50=A0am, Keith M <kmo...@gmail.com> wrote:
> So being new to FPGAs, I've bought a Digilent 3E Starter Kit that has
> onboard ddr memory to which I'd like to get access.
>
> What's the best way to get a simple read/write interface to the
> memory? =A0I'm learning verilog and prefer examples or code written in
> it.
>
> I've tried a couple options:
>
> 1. Memory Interface Generator from Xilinx. (MIG 23) =A0This looks like
> the most robust solution, but the code that is output seems overly
> complicated, mostly uncommented, and the example test bench is
> anything but straight forward. =A0The user guide UG086 is written ok.
>
> 2. Couple of opencores solutions, including ddr ctrl (the non wishbone
> version) =A0While it's commented better, there is zerodocumentation. =A0I
> can't get it to synthesize even though it's specifically designed for
> my kit. =A0The problems are related to .ucf constraints, but when I
> manually look through them, most of them seem ok. =A0It's as if the
> format of the .ucf file is not what XST(or whatever component that is)
> expects, so it generates about 40 errors.
>
> Is accessing this DDR memory more simple viaPicoblazeor Microblaze?
> Is Microblaze and associated parts free? =A0I didn't get any CDs
> whatsoever w/ my board.
>
> Thanks
>
> Keith
inorder to access thew memory u either need to perform most of the pre
functions say initialising ,charging,commands etc . Better u use the
controller
i was able to use the opencores ddr controller however i am
stuck at the point of controlling the ddr controller with the
picobalze controller.
if u know a way please share it with me
Article: 138889Walter Banks wrote: > Herbert Kleebauer wrote: > > I don't think it is possible to make a serial CPU smaller than > > a parallel one. Here is a 16 bit CPU with interrupt support > > built with only 65 flip-flop's. > Serial processors only require a 1 bit alu, registers are shift registers > with a single in and out data line. The availability of large lowcost > bit serial memories like SD cards opens the possibility of creating a > small processor. Yes, you will save some logic if you use a 1 bit alu, but that's not as much as you have to add for controlling the serial alu. The goal was to make the smallest possible CPU which can at least address 32 kbyte RAM and supports interrupts. The first idea was to use a serial design, but if you spend some time thinking about it, then you will see that you never can get it as small as a 16 bit design (also a 8 bit design is bigger than a 16 bit design). This is at least true for the gate count, if you also consider the routing resources then the difference may be smaller.Article: 138890
On 13 Mar, 21:56, Herbert Kleebauer <k...@unibwm.de> wrote: > Walter Banks wrote: > > Herbert Kleebauer wrote: > > > I don't think it is possible to make a serial CPU smaller than > > > a parallel one. Here is a 16 bit CPU with interrupt support > > > built with only 65 flip-flop's. > > Serial processors only require a 1 bit alu, registers are shift registers > > with a single in and out data line. The availability of large lowcost > > bit serial memories like SD cards opens the possibility of creating a > > small processor. > > Yes, you will save some logic if you use a 1 bit alu, but that's not > as much as you have to add for controlling the serial alu. > > The goal was to make the smallest possible CPU which can at > least address 32 kbyte RAM and supports interrupts. The first > idea was to use a serial design, but if you spend some time > thinking about it, then you will see that you never can get > it as small as a 16 bit design (also a 8 bit design is bigger > than a 16 bit design). This is at least true for the gate count, > if you also consider the routing resources then the difference > may be smaller. it all depends the useage scenario if BLOCK RAMs are available, it one concept if not it different... mproz executing code from serial flash would be highly inefficient in terms of clock cycles wasted so it different goals. mproz uses 3 words per instruction, if code space is 8mb or 8gb as for in place execute from sd then it would be 12 bytes to read per instruction a serialized design that aligns alu operations with the speed of serially fetched instruction bits would achive much better speed AnttiArticle: 138891
On Fri, 13 Mar 2009 13:39:33 -0700 (PDT), Antti.Lukats wrote: >a serialized design that aligns alu operations >with the speed of serially fetched instruction >bits would achive much better speed I have absolutely no idea what you mean by this. I tend to agree with Herbert Kleebauer: if you are doing something highly iterative and pipelined, and your algorithm is fixed, then a bit-serial approach may save significant resources; but for a CPU that needs to do real work that is not predictable in advance, I don't see the advantage. The parts of a CPU that can reasonably be bit-serialized are not likely to be a large fraction of the whole design's area cost, and there is a non-trivial control overhead. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 138892
Well, I herewith declare to happily ignore the DMCA while beeing outside of the US. I follow the laws of my country and international treaties. That is more than the US government can claim to do. Kolja > I herein promise todo all my best not to post on threads where > previous postings may violate DMCA or copyrights. And of course I will > not make such postings myself as I have not done to my knowledge > before either.Article: 138893
Herbert Kleebauer wrote: > Walter Banks wrote: > > Herbert Kleebauer wrote: > > > > I don't think it is possible to make a serial CPU smaller than > > > a parallel one. Here is a 16 bit CPU with interrupt support > > > built with only 65 flip-flop's. > > > Serial processors only require a 1 bit alu, registers are shift registers > > with a single in and out data line. The availability of large lowcost > > bit serial memories like SD cards opens the possibility of creating a > > small processor. > > Yes, you will save some logic if you use a 1 bit alu, but that's not > as much as you have to add for controlling the serial alu. > Bit serial will be slow but remember that the data paths to registers are reduced. The logic is considerably simpler. There are other advantages as well like the ability to have variable length data types, reducing the number of instructions to do multi-byte math. Bit serial is slower, to be sure. The controller needed to use a SD card is not very much. There are many applications that could be well suited to a bit serial processor, for example a data logger. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.comArticle: 138894
On 13 Mar, 21:22, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Fri, 13 Mar 2009 13:39:33 -0700 (PDT), Antti.Lukats wrote: > >a serialized design that aligns alu operations > >with the speed of serially fetched instruction > >bits would achive much better speed > > I have absolutely no idea what you mean by this. I think he was implying that ALU could work serially in the clocks to fectch in a word or SPI nibble of the next instruction. Although I am not sure this would be that beneficial beyond a certain instruction complexity due to the number of seperate multiplexed particulates (steps) of the number of instructions, making a counter, decode complexity and seperation of writeback assignments to register intermediates. Oh yes and the comparator for checking when the number of bits has been completed. > I tend to agree with Herbert Kleebauer: if you > are doing something highly iterative and pipelined, > and your algorithm is fixed, then a bit-serial > approach may save significant resources; but > for a CPU that needs to do real work that is > not predictable in advance, I don't see > the advantage. =A0The parts of a CPU that can > reasonably be bit-serialized are not likely > to be a large fraction of the whole design's > area cost, and there is a non-trivial > control overhead. Yes the control overhead can be larger than a lot of people expect. The routing reduction is not as critical, due to channels of fpga, or number of metal layers in custom ASIC. I would be very interested in finding out what 16 instructions would be favorite for such a nibble sd processor. cheers jackoArticle: 138895
>> looks like opencores.org changes it's hosting strategies without asking >> their user and core providers. At the moment the CVS access is down and >> it looks like they changed to SVN. Without a notice to the core >> providers. >> > Hi Martin, > > ORSoC AB, who took over responsibility for OpenCores in late 2007, have > reimplemented the entire website back end. The switch over was earlier > this week, but I believe has been in planning since the take over. At the > same time they have switched to Subversion. That is ok - we shall not start to discuss if CVS or SVN is better (or git ;-). However, the switch was never announced to the developers. We did notice it from the fact that the CVS access just did not work anymore. If you're in a critcal development phase that's no fun when you have to switch the repository system without planning ahead.... Cheers, MartinArticle: 138896
Hi Marcus,
I did post my complain about opencores to this group as my comments
on the redesign and the new rules on access policies have been
filtered out from the oc mailing list.
Let's say it friendly: I don't think it's the best policy to censor
slightly critical comments on a list for discussion on open-source
projects.
And now here my original complains from around half year ago ;-) I don't
like that access to open-source projects is restricted to registered
user because:
1. that's in my opinion against the OS philosophy
2. it makes is uncomfortable to 'just check a project'
3. sending a link to one of my files in the CVS web view is not
practical anymore
4. it spams the list of possible developers. When I want to add
one to the project it takes minutes to find that person in a web
list box that contains hundreds (or more) entries
I really liked opencores, but I get the feeling that it is controlled
too much, or in a way I don't like...
BTW: I'm not a user who is against all changes.
Cheers,
Martin
----- Original Message -----
From: <marcus.erlandsson@gmail.com> Newsgroups: comp.arch.fpga Sent:
Friday, March 13, 2009 12:21 PM Subject: Re: What happens at
opencores.org?
The OpenCores team are putting in enormous resources in making sure
that the OpenCores will continue to exist/expand. It is important
that the platform can continue to support good services to both users
and core-providers, also for the next 10-20 years. If possible it is
also good if we can provide an even greater “trust” and “quality” in
the cores at OpenCores.
The complete redesign of the OpenCores-platform enable us to support
all users with a future-proof and professional site. It also support
integrating new functionalities much easier then before, since the
old platform had grown out of proportion.
We feel that we have listen to the community, since we get allot of
Feedback - i.e. complaining about poor statistics, forum structure,
etc. But unfortunately we also get some few complaints from a small
portion of users that are just against all changes :-(
But for those users who has more concrete suggestion/ideas/
improvements, feel free to contact us at oc-team@opencores.org
Best regards,
The OC-team
Article: 138897When I do this in component instantiation statement "...out_port=>out_port, read_strobe=>open..." i get warnings. I don't need read_strobe so I leave it open. (input pins are all used or tied). XST gives a warning. Is there any smarter way to "not use a output pin" or I just ignore that warning ? Thank you !Article: 138898
On Mar 13, 8:43=A0pm, "Mad I.D." <madi...@gmail.com> wrote: > When I do this in component instantiation statement > "...out_port=3D>out_port, read_strobe=3D>open..." > i get warnings. > > I don't need read_strobe so I leave it open. (input pins are all used > or tied). XST gives a warning. Is there any smarter way to "not use a > output pin" or I just ignore that warning ? > > Thank you ! If you right click on the message, there are options to filter the message which leaves it to the designer's discretion. I've tried connecting a dummy wire to the unused output and xor similar wires to an unused output pin. This flags me that I have looked at the situation but does result in code clutter, unrealized trimming of circuitry, additional unneeded circuitry, etc.Article: 138899
On Mar 13, 9:20=A0pm, newman5...@yahoo.com wrote: > On Mar 13, 8:43=A0pm, "Mad I.D." <madi...@gmail.com> wrote: > > > When I do this in component instantiation statement > > "...out_port=3D>out_port, read_strobe=3D>open..." > > i get warnings. > > > I don't need read_strobe so I leave it open. (input pins are all used > > or tied). XST gives a warning. Is there any smarter way to "not use a > > output pin" or I just ignore that warning ? > > > Thank you ! > > If you right click on the message, there are options to filter the > message which leaves it to the designer's discretion. =A0I've tried > connecting a dummy wire to the unused output and xor similar wires to > an unused output pin. =A0This flags me that I have looked at the > situation but does result in code clutter, unrealized trimming of > circuitry, additional unneeded circuitry, etc. IIRC, if one can omit the output within coregen so it does not show up in the instance, that helps too.
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