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 Mar 15, 10:00=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Mar 15, 5:30=A0am, james <bu...@bud.u> wrote: > > > > > On Sun, 14 Mar 2010 07:37:17 -0700 (PDT), Antti > > > <antti.luk...@googlemail.com> wrote: > > > |On Mar 14, 4:14=A0pm, Sharath Raju <brshar...@gmail.com> wrote: > > |> I am trying to send data from the FPGA to the ethernet transeiver on > > |> the Nu Horizons Spartan 3A DSP board. > > |> There is an on-board Micrel KSZ8041NL transceiver, and Nu Horizons h= as > > |> provided a wrapper (.bit =A0file) to talk to the transceiver. I have > > |> downloaded it to the board, but don't know how to use the wrapper as > > |> there is not much documentation, besides just the bit file. > > |> > > |> Can anyone help ? > > | > > |.bit as wrapper? > > |you are mistaken > > | > > |.bit files are pre made demos only so you can only use to try out the > > |factory demo > > |you cant use it own designs at all > > | > > |and as Nu horizons is no longer an Xilinx disti, i bet you get nil > > |xilinx support from nu > > | > > |antti > > | > > | > > | > > |++++++++++ > > > 32% of annual sales gone! Man is that a shocker for Nu Horizons. > > > So I wonder what the "new" direction is for Xilinx? > > > james > > single disti > > Antti Thanks for your replies. @ Antti: I think I shall look at the following opencores implementation: http://www.opencores.org/project,ethernet_tri_mode. Does anybody have any particular suggestions ?.Article: 146376
hello, i need help. i work over an algo in C langage that verifies a design described in VHDL for it, i want take all informations from my vhdl code for use them in my programme in C and i don't know how.Article: 146377
Hi, We have generated altera ram ip (RAM: 2-port) from Memory Compiler in MegaWizard Manager. We are operating in mode Mixed-Port Read-During- Write as mentioned in aiigx_51003.pdf (pg no:3-18, fig no:3-20). When we simulate this ram in modelsim the behavior of ram in this mode is not matching with section 3-20. of aiigx_51003.pdf The use case in this mode is one port reading and the other port writing to the same address location with the same clock. We have chosen option: old data. In old data mode, a read-during-write operation to different ports causes the RAM outputs to reflect the old data at that address location. But we are seeing don't care 'X' at the output in our simulation mode. Please suggest me to solve this kind of issue. We are simulating the way it is mentioned in fig no:3-20 of aiigx_51003.pdf Regards, SrikanthArticle: 146378
On Mon, 15 Mar 2010 02:07:47 -0500, "weldat" <gwelekiros@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: >>On Mar 12, 5:36=A0am, "weldat" <gweleki...@gmail.com> wrote: >>> =A0Hi all; >>> may someone explain to me how to add memory to store my microBlaze >progra= >>m >>> if my system is out of memory? >>> thank you in advance >> >>I assume that "by out of memory," you mean that you do not have enough >>BRAMs to store the program. If so, then you need to provide some kind >>of non-volatile storage, like a flash EEPROM. You then need to >>determine whether the flash access time is fast enough to allow you to >>run the program directly out of it, or whether you need faster program >>memory, either by using BRAMs and banking or perhaps by adding >>external SRAM/SDRAM/DDR SDRAM. >> >>-a >> >hi >i got this message ... >/cygdrive/c/Xilinx/10.1/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.1/../../../../microblaze-xilinx-elf/bin/ld.real: >section .init [00000050 -> 00000077] overlaps section .text [00000050 -> >00012d2f] section .text [00000050 -> 00012d2f] This section is somewhere over 80 kilobytes... You need to: (a) increase the size of the program memory - at least to 96kb - IF the FPGA has more memory available, (you may also need to learn how to write linker scripts) or - most likely the real problem (b) reduce the size of the program. Look at the symbol tables and see what's taking up so much space. Rewrite it smaller or eliminate it. For example: there are simpler versions of "printf" - like xil_printf - that can save several kB of memory at a stroke. If the code is cobbled together from different places it may waste even more space by using both. If the program uses floating point math, consider using scaled integer or fixed point instead. - BrianArticle: 146379
On Mon, 15 Mar 2010 02:51:22 -0700 (PDT), lolita grenoble <lolita.grenoble@gmail.com> wrote: >hello, >i need help. >i work over an algo in C langage that verifies a design described in >VHDL >for it, i want take all informations from my vhdl code for use them in >my programme in C and i don't know how. One way is to write a file in your VHDL code (running it in the simulator) then read that file in your C code. - BrianArticle: 146380
rickman wrote: > On Mar 10, 8:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >> On Mar 10, 4:25 pm, Andy <jonesa...@comcast.net> wrote: >> >> >> >>> On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >>>> On Mar 10, 10:06 am, Andy <jonesa...@comcast.net> wrote: >>>>> On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >>>>>> I would strongly encourage you to change the RESET function from >>>>>> asynchronous to synchronous. >>>>> On what basis do you make this recommendation, and what does this have >>>>> to do with latches? >>>>> Andy >>>> Synchronous versus asynchronous resets have been discussed at length >>>> in other threads. >>>> Asynchronous resets have their place in a designer's toolbox, however >>>> they should be used sparingly. Some reasons to use these are for >>>> handshakes crossing clock domains, anticipated loss of clock and >>>> asynchronous inputs to the synchronous domain. >>>> In a synchronous domain, such as the original state machine example, >>>> the asynchronous functionality offers no additional benefit in FPGAs >>>> as the area cost is identical for both. >>>> Asynchronously asserting and de-asserting a reset across multiple >>>> registers may/will result in the registers being released before and >>>> after a clock edge due to large net delay and skew on the reset net. >>>> This will result in different parts of a design coming out of reset >>>> across clock boundaries and being out of sync with each other. >>>> Synchronous resets simplify timing analysis and timing closure without >>>> having to worry about the consequences of the asynchronous functions >>>> and how to correctly constrain them. >>>> I often see problems with FPGA designs that are built with >>>> asynchronous resets, but I have yet to see a problem with a FPGA >>>> design that was traced to a synchronous reset. >>>> In an FPGA there is no downside to a synchronous reset, but there are >>>> many pitfalls with an asynchronous reset. >>>> None of this has anything to do with a latch, which you also want to >>>> avoid using in an FPGA. >>>> Ed McGettigan >>>> -- >>>> Xilinx Inc. >>> Given that most sources of reset signals are not already synchronized >>> to the clock domain(s) that need resetting, both asynchronous and >>> syncrhonous resets require at least the deasserting edge to be >>> synchronized. Proper syncrhonization for each case takes the same >>> amount of design effort and resources. >>> I will agree that getting the constraints set to make sure that the >>> synchronous deassertion path meets timing in an asynchronously reset >>> system can be non-obvious, but that is a tools issue, not a design >>> issue (in other words, fix the tools!) >>> Given that an asynchronous reset reliably resets the circuit, >>> regardless of the presence or stability of the clock signal, when an >>> asynchronous reset is correctly designed, it is a more reliable reset >>> than a synchronous one. >>> Andy- Hide quoted text - >>> - Show quoted text - >> I wouldn't take it as a given that most resets are not already >> synchronized to the clock domains. Resets are routinely used based on >> termination count, end of packet, return to state0 from other states >> or invalid states, etc.... All of these cases would be within the >> same clock domain. >> >> Placing the onus of creating a reliable design on software tools to >> correctly determine the designer's intent for timing paths that are >> "non-obvious" is not a working solution IMHO. >> >> The cons of an asynchronous reset significantly outweigh the single >> pro that the reset will occur in the absence of clock. >> >> Ed McGettigan >> -- >> Xilinx Inc. > > I don't follow that at all. I use async resets all the time, but I > use them appropriately. I don't expect them to release all FFs at the > same time and design that way. That's all it takes. No magic, mo > complex design techniques. I just don't assume a counter will have > all bits start at the same clock cycle, give or take one cycle. But a > binary counter will only increment the lsb if started at count 0. So > it will start correctly if the rest of the bits are released in the > next clock cycle or the one before. My state machine designs include > a start state that is just to allow the state machine to release from > reset. The list goes on. But nothing on the list is hard to > understand or to implement. More importantly, an async reset and the > small amount of logic required to release FFs from the async reset is > less logic than adding a sync reset to every FF in the design. AND > it will operate irrespective of the state of the clock! > > Rick AFAIK, the reset and set ports in flip flops in Xilinx FPGAs can be configured to be either asynchronous or synchronous. So there is no extra logic required to implement synchronous resets. In fact, if you don't specify a reset for a register, the reset and set ports can be used as logic inputs, so you can put more logic in a slice. If your design has outputs that are critical you can use async reset on the output registers or use logic to set the output asynchronously. I use a reset circuit that holds the design in reset until the DCM/PLL's locked output is asserted, and then some cycles. Then I know I have a stable clock before the design starts up. MagneArticle: 146381
On Sun, 14 Mar 2010 20:47:24 -0400 Jeff Cunningham <jcc@sover.net> wrote: > On 3/13/10 10:35 PM, rickman wrote: > >> > >> > 1 million, you won't get their attention or even a quote. > >> I can get quotes from others, so why not from TierLogic ? > > > > I don't understand the question. The point is they can't make > > enough money from a small user to make it worth their while. So > > they exclude the engineers that won't make them much money and deal > > with the flak from that rather than get a bad rep from not being > > able to support every engineer with a wild hair. > > > > What part of this is hard to understand? > > I don't understand why selling to the small users and not supporting > them well and therefore losing some sales from them because of "bad > rep" would be a worse business strategy than imposing a boycott on > yourself and not selling any parts at all to any of that group of > people. Are you saying that the bad rep among the little guys would > rub off onto even the big customers that do get good support? It > seems kind of weird to me, but what do I know. > > Jeff Absolutely it would. When a vendor agrees to work with me and then leaves me hanging because my project is important to my company but not to theirs, it really ticks me off. When I change jobs, I carry that grudge and, when asked my opinion of that company, will give it freely. It's 100% better to not work with someone at all than to hang them out to dry. If I never design you in in the first place I've lost nothing. If I've got a prototype in hand, and NOW you're not interested, we've got a problem. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146382
On Sun, 14 Mar 2010 23:30:44 -0400 james <bubba@bud.u> wrote: > On Sun, 14 Mar 2010 07:37:17 -0700 (PDT), Antti > <antti.lukats@googlemail.com> wrote: >=20 > |On Mar 14, 4:14=A0pm, Sharath Raju <brshar...@gmail.com> wrote: > |> I am trying to send data from the FPGA to the ethernet transeiver > on |> the Nu Horizons Spartan 3A DSP board. > |> There is an on-board Micrel KSZ8041NL transceiver, and Nu Horizons > has |> provided a wrapper (.bit =A0file) to talk to the transceiver. I > have |> downloaded it to the board, but don't know how to use the > wrapper as |> there is not much documentation, besides just the bit > file. |> > |> Can anyone help ? > | > |.bit as wrapper? > |you are mistaken > | > |.bit files are pre made demos only so you can only use to try out the > |factory demo > |you cant use it own designs at all > | > |and as Nu horizons is no longer an Xilinx disti, i bet you get nil > |xilinx support from nu > | > |antti > | > | > | > |++++++++++ >=20 > 32% of annual sales gone! Man is that a shocker for Nu Horizons. >=20 > So I wonder what the "new" direction is for Xilinx? >=20 > james All AvNet, all the time. It's a shame; my NuHo Xilinx FAE was really good. --=20 Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146383
On Mon, 15 Mar 2010 12:07:24 +0000 Brian Drummond <brian_drummond@btconnect.com> wrote: > On Mon, 15 Mar 2010 02:51:22 -0700 (PDT), lolita grenoble > <lolita.grenoble@gmail.com> wrote: > > >hello, > >i need help. > >i work over an algo in C langage that verifies a design described in > >VHDL > >for it, i want take all informations from my vhdl code for use them > >in my programme in C and i don't know how. > > One way is to write a file in your VHDL code (running it in the > simulator) then read that file in your C code. > > - Brian Specifically, your search term is STD.TEXTIO -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146384
On Mar 12, 12:33=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > From the official TIER website: > > "Support: > Tier Logic intends support to be a differentiator from the mainstream > FPGA vendors, who increasingly focus their support on only a few > select customers, ignoring or providing poor-quality support to all > but their largest accounts. Our approach is not to attempt to support > thousands of customers, but to sign up to deliver high-quality support > to every customer with whom we engage. > > Please register to get full access to the Tier Logic website." > > Peter says: > They hired a 13-year Altera veteran as VP of marketing and sales. > Where did he pick up such contorted writing and negative reasoning ? > It is unprofessional, to say the least. So, maybe the first response to ANY WebCase/support question won't be, "Please send us your design." -aArticle: 146385
On Mar 13, 9:59=A0pm, GaLaKtIkUs=99 <taileb.me...@gmail.com> wrote: > I googled for s g.723.1 codec ipcore for xilinx FPGA but didn't find > any :( > Please help! > > Mehdi I Googled for "Next Week's Winning Lotto Numbers" and didn't find those either. Here's a couple of links for you: <http://www.vhdl-online.de/tutorial/englisch/inhalt.htm> <http://en.wikipedia.org/wiki/G.723.1> RKArticle: 146386
On Mar 15, 2:30=A0am, whygee <y...@yg.yg> wrote: > rickman wrote: > > I agree that there are opportunities at the low end. =A0I don't know > > exactly what mix is optimal, but even the XP3C part I am using is an > > older technology for Lattice. =A0If they make an XP2 in 100 pin part, > > the price would be lower than in the higher pin count packages and > > that is what I would be using. =A0I need the gates! > > similar problem with Actel, > I was explained that the large die size can't fit in smaller packages > than what is proposed... too bad :-/ I'm not familiar with Actel, but with the others I know it is not a die size issue. They use even smaller packages than the 100TQFP, but they are BGA (chip scale?) or worse, LGA packaging or in one Actel case I seem to recall a possibly difficult to use 132 pin QFN. If the die fit these packages, they will fit in a 100TQFP. They just don't want to support this package for marketing reasons. I assume they have determined the effort is not justified by the market... I can't tell them what their markets are, but to some extent it is a build it and they will come. If the part prices have a floor determined by testing time which in turn depends on IO count, it seems they could drop even high volume pricing even more by using these smaller and lower cost packages. I guess there is a reason why I'm not in FPGA marketing... maybe I just don't see things the same way... RickArticle: 146387
On Mar 15, 1:29=A0pm, Andy Peters <goo...@latke.net> wrote: > On Mar 12, 12:33=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > > > > > From the official TIER website: > > > "Support: > > Tier Logic intends support to be a differentiator from the mainstream > > FPGA vendors, who increasingly focus their support on only a few > > select customers, ignoring or providing poor-quality support to all > > but their largest accounts. Our approach is not to attempt to support > > thousands of customers, but to sign up to deliver high-quality support > > to every customer with whom we engage. > > > Please register to get full access to the Tier Logic website." > > > Peter says: > > They hired a 13-year Altera veteran as VP of marketing and sales. > > Where did he pick up such contorted writing and negative reasoning ? > > It is unprofessional, to say the least. > > So, maybe the first response to ANY WebCase/support question won't be, > "Please send us your design." Yeah, but put yourself in their shoes. I'd hate to respond to calls saying, "It doesn't work when I do this". "Well don't do that!" Talk about your thankless jobs! RickArticle: 146388
On Mar 15, 8:14=A0am, Magne Munkejord <magnem...@yahoo.no> wrote: > rickman wrote: > > On Mar 10, 8:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > >> On Mar 10, 4:25 pm, Andy <jonesa...@comcast.net> wrote: > > >>> On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > >>>> On Mar 10, 10:06 am, Andy <jonesa...@comcast.net> wrote: > >>>>> On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > >>>>>> I would strongly encourage you to change the RESET function from > >>>>>> asynchronous to synchronous. > >>>>> On what basis do you make this recommendation, and what does this h= ave > >>>>> to do with latches? > >>>>> Andy > >>>> Synchronous versus asynchronous resets have been discussed at length > >>>> in other threads. > >>>> Asynchronous resets have their place in a designer's toolbox, howeve= r > >>>> they should be used sparingly. =A0Some reasons to use these are for > >>>> handshakes crossing clock domains, anticipated loss of clock and > >>>> asynchronous inputs to the synchronous domain. > >>>> In a synchronous domain, such as the original state machine example, > >>>> the asynchronous functionality offers no additional benefit in FPGAs > >>>> as the area cost is identical for both. > >>>> Asynchronously asserting and de-asserting a reset across multiple > >>>> registers may/will result in the registers being released before and > >>>> after a clock edge due to large net delay and skew on the reset net. > >>>> This will result in different parts of a design coming out of reset > >>>> across clock boundaries and being out of sync with each other. > >>>> Synchronous resets simplify timing analysis and timing closure witho= ut > >>>> having to worry about the consequences of the asynchronous functions > >>>> and how to correctly constrain them. > >>>> I often see problems with FPGA designs that are built with > >>>> asynchronous resets, but I have yet to see a problem with a FPGA > >>>> design that was traced to a synchronous reset. > >>>> In an FPGA there is no downside to a synchronous reset, but there ar= e > >>>> many pitfalls with an asynchronous reset. > >>>> None of this has anything to do with a latch, which you also want to > >>>> avoid using in an FPGA. > >>>> Ed McGettigan > >>>> -- > >>>> Xilinx Inc. > >>> Given that most sources of reset signals are not already synchronized > >>> to the clock domain(s) that need resetting, both asynchronous and > >>> syncrhonous resets require at least the deasserting edge to be > >>> synchronized. Proper syncrhonization for each case takes the same > >>> amount of design effort and resources. > >>> I will agree that getting the constraints set to make sure that the > >>> synchronous deassertion path meets timing in an asynchronously reset > >>> system can be non-obvious, but that is a tools issue, not a design > >>> issue (in other words, fix the tools!) > >>> Given that an asynchronous reset reliably resets the circuit, > >>> regardless of the presence or stability of the clock signal, when an > >>> asynchronous reset is correctly designed, it is a more reliable reset > >>> than a synchronous one. > >>> Andy- Hide quoted text - > >>> - Show quoted text - > >> I wouldn't take it as a given that most resets are not already > >> synchronized to the clock domains. =A0Resets are routinely used based = on > >> termination count, end of packet, return to state0 from other states > >> or invalid states, etc.... =A0All of these cases would be within the > >> same clock domain. > > >> Placing the onus of creating a reliable design on software tools to > >> correctly determine the designer's intent for timing paths that are > >> "non-obvious" is not a working solution IMHO. > > >> The cons of an asynchronous reset significantly outweigh the single > >> pro that the reset will occur in the absence of clock. > > >> Ed McGettigan > >> -- > >> Xilinx Inc. > > > I don't follow that at all. =A0I use async resets all the time, but I > > use them appropriately. =A0I don't expect them to release all FFs at th= e > > same time and design that way. =A0That's all it takes. =A0No magic, mo > > complex design techniques. =A0I just don't assume a counter will have > > all bits start at the same clock cycle, give or take one cycle. =A0But = a > > binary counter will only increment the lsb if started at count 0. =A0So > > it will start correctly if the rest of the bits are released in the > > next clock cycle or the one before. =A0My state machine designs include > > a start state that is just to allow the state machine to release from > > reset. =A0The list goes on. =A0But nothing on the list is hard to > > understand or to implement. =A0More importantly, an async reset and the > > small amount of logic required to release FFs from the async reset is > > less logic than adding a sync reset to every FF in the design. =A0 AND > > it will operate irrespective of the state of the clock! > > > Rick > > AFAIK, the reset and set ports in flip flops in Xilinx FPGAs can be > configured to be either asynchronous or synchronous. So there is no > extra logic required to implement synchronous resets. > In fact, if you don't specify a reset for a register, the reset and set > ports can be used as logic inputs, so you can put more logic in a slice. You would think that. I just had to change some code to eliminate a sync reset on a register to get rid of one level of LUTs in a Lattice design which has a similar if not same FF structure with the dedicated LSR input (Local Set/Reset). Synplify seems to not know how to use that. Maybe this would get changed by the mapper, but I don't think it does that. I was looking at it in the synthesis tool. Have you tried an example? Does Synplify do a better job with the Xilinx parts than they do with Lattice parts? I'm not convinced they do a good job with the arithmetic units. It is more than once I've seen an adder chain duplicated to get the carry out of the top! > If your design has outputs that are critical you can use async reset on > the output registers or use logic to set the output asynchronously. > > I use a reset circuit that holds the design in reset until the DCM/PLL's > locked output is asserted, and then some cycles. Then I know I have a > stable clock before the design starts up. This issue is very complex in the real world. Once you find a solution you like, most people stick with it regardless. I haven't found a problem with the async reset and it always starts the chip in the same state no matter what! I just pay a little attention to how my circuits come out of an async reset which I don't find difficult at all. I haven't tried the PLL yet. That may be in a later design, so I may have to change my methods. RickArticle: 146389
On Sun, 14 Mar 2010 22:00:45 -0700 (PDT), Antti <antti.lukats@googlemail.com> wrote: |On Mar 15, 5:30 am, james <bu...@bud.u> wrote: |> On Sun, 14 Mar 2010 07:37:17 -0700 (PDT), Antti |> |> <antti.luk...@googlemail.com> wrote: |> |> |On Mar 14, 4:14 pm, Sharath Raju <brshar...@gmail.com> wrote: |> |> I am trying to send data from the FPGA to the ethernet transeiver on |> |> the Nu Horizons Spartan 3A DSP board. |> |> There is an on-board Micrel KSZ8041NL transceiver, and Nu Horizons has |> |> provided a wrapper (.bit file) to talk to the transceiver. I have |> |> downloaded it to the board, but don't know how to use the wrapper as |> |> there is not much documentation, besides just the bit file. |> |> |> |> Can anyone help ? |> | |> |.bit as wrapper? |> |you are mistaken |> | |> |.bit files are pre made demos only so you can only use to try out the |> |factory demo |> |you cant use it own designs at all |> | |> |and as Nu horizons is no longer an Xilinx disti, i bet you get nil |> |xilinx support from nu |> | |> |antti |> | |> | |> | |> |++++++++++ |> |> 32% of annual sales gone! Man is that a shocker for Nu Horizons. |> |> So I wonder what the "new" direction is for Xilinx? |> |> james | |single disti | |Antti That either means themselves or Avnet who is currently their only distributor left. I wonder if that also means that Digikey is out also? jamesArticle: 146390
On Mar 15, 9:42=A0pm, james <bu...@bud.u> wrote: > On Sun, 14 Mar 2010 22:00:45 -0700 (PDT), Antti > > <antti.luk...@googlemail.com> wrote: > > |On Mar 15, 5:30 am, james <bu...@bud.u> wrote: > |> On Sun, 14 Mar 2010 07:37:17 -0700 (PDT), Antti > |>|> <antti.luk...@googlemail.com> wrote: > > |> > |> |On Mar 14, 4:14 pm, Sharath Raju <brshar...@gmail.com> wrote: > |> |> I am trying to send data from the FPGA to the ethernet transeiver o= n > |> |> the Nu Horizons Spartan 3A DSP board. > |> |> There is an on-board Micrel KSZ8041NL transceiver, and Nu Horizons = has > |> |> provided a wrapper (.bit file) to talk to the transceiver. I have > |> |> downloaded it to the board, but don't know how to use the wrapper a= s > |> |> there is not much documentation, besides just the bit file. > |> |> > |> |> Can anyone help ? > |> | > |> |.bit as wrapper? > |> |you are mistaken > |> | > |> |.bit files are pre made demos only so you can only use to try out the > |> |factory demo > |> |you cant use it own designs at all > |> | > |> |and as Nu horizons is no longer an Xilinx disti, i bet you get nil > |> |xilinx support from nu > |> | > |> |antti > |> | > |> | > |> | > |> |++++++++++ > |> > |> 32% of annual sales gone! Man is that a shocker for Nu Horizons. > |> > |> So I wonder what the "new" direction is for Xilinx? > |> > |> james > | > |single disti > | > |Antti > > That either means themselves or Avnet who is currently their only > distributor left. I wonder if that also means that Digikey is out > also? > > james you see many spartan-6 devices at digikey ?? digikey is not disti, its place to get some stuff sometimes i dont AnttiArticle: 146391
I am converting an integer equation to use numeric_std data types and it looks rather awkward. Here is the equation... PhaseStep <= (IntgrPhase + (PROPGAIN * DataCount) + FreqStep) mod MODULUS; The names in caps are integer constants, PhaseStep and FreqStep are unsigned while IntgrPhase and DataCount are signed, all four the same length, 16 bits. The true range of DataCount will be very limited so it is invalid that it will cause an overflow of the result. In fact, it is considered an operational error if any of this causes an overflow in the result... that is the inputs must have been out of whack, not the circuit. So I'm not worried about the math at that level. I'm concerned about how to get the circuit I want without a lot of difficult typing of syntax. I just want this stuff to be added to produce a 16 bit result. When doing this using integer arithmetic it all works well. In simulation it only barfs if a value exceeds its range and the synthesis result uses the correct number of bits in the implementation. I don't see it using any extra bits in the calculations which makes sense, why calculate bits you aren't using in the end? To add the signed and unsigned values, I believe I will have to add a bit to the unsigned FreqStep before adding to the signed values. The significant bits will not flow into the added bit, so it can be dropped in the end. But this will complicate the result a lot. PhaseStep <= resize(unsigned(IntgrPhase + (PROPGAIN * DataCount) + signed(resize(FreqStep,STEPWIDTH+1)) mod MODULUS), STEPWIDTH); Am I making this more complicated than it needs to be? If I just convert FreqStep to signed without the resize, it will treat the msb as a sign bit and corrupt the value, right? I guess the fact that I call it a signed value doesn't change the circuit, but it will change the simulation, right? The other thing I could do is to convert them all to integer and then back, but that is no less messy. Any ideas on a way to make this expression simpler? RickArticle: 146392
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
> I am converting an integer equation to use numeric_std data types and
> it looks rather awkward. Here is the equation...
> PhaseStep <= (IntgrPhase + (PROPGAIN * DataCount) + FreqStep) mod
> MODULUS;
> The names in caps are integer constants, PhaseStep and FreqStep are
> unsigned while IntgrPhase and DataCount are signed, all four the same
> length, 16 bits. The true range of DataCount will be very limited so
> it is invalid that it will cause an overflow of the result.
How big can the values be? The result can't overflow because
of the MOD. (It can't exceed MODULUS-1), but multiplying two
16 bit integers can reach 32 or so (signed or unsigned?) bits.
> In fact,
> it is considered an operational error if any of this causes an
> overflow in the result... that is the inputs must have been out of
> whack, not the circuit. So I'm not worried about the math at that
> level. I'm concerned about how to get the circuit I want without a
> lot of difficult typing of syntax.
If DataCount can't get so big, then a lookup table based on the
constant PROPGAIN would be easy and fast. That is, do:
PhaseStep <= (IntgrPhase + ((PROPGAIN * DataCount)mod MODULUS) + FreqStep)
mod MODULUS;
Then, depending on the size of IntgrPhase and FreqStep, another
table or some simple adder logic could do the second modulus.
It is somewhat easier if MODULUS is a power of two, but you can
still do it even if it isn't. Another possibility so to multiply
DataCount by an appropriately scaled PROPGAIN such that a power of
two modulus can be used, then multply the result to get the correct
MODULUS. You have to be careful with rounding, but I believe
that can be done. Doing division by multiplication with an
appropriately scaled reciprocal is common, and the rounding is
well understood. It isn't quite as obvious for mod, but I believe
it can still be done. (The latter assumes you have hardware
multipliers available, as many current FPGAs have.)
-- glen
Article: 146393This may be a silly question, but why do you need to convert it to signed/unsigned? If it works in integer, leave it be... The simulation will be much faster, and the circuit just as good. Glen sounds like he's got some good implementation ideas, but if you're primarily interested in expressing the problem in a simple readable way, integer types are the clear winner. This is one of those golden examples of why I like integers so much! Or do you want it to be scalable to > 31 bits? That would be an example of why I want integer to be bigger! AndyArticle: 146394
On Mar 15, 6:12=A0pm, Andy <jonesa...@comcast.net> wrote: > This may be a silly question, but why do you need to convert it to > signed/unsigned? If it works in integer, leave it be... The simulation > will be much faster, and the circuit just as good. Glen sounds like > he's got some good implementation ideas, but if you're primarily > interested in expressing the problem in a simple readable way, integer > types are the clear winner. This is one of those golden examples of > why I like integers so much! > > Or do you want it to be scalable to > 31 bits? That would be an > example of why I want integer to be bigger! > > Andy Thanks for the reply. No, I don't need > 31 bits. I just am using this in a case where all the connecting signals are signed/unsigned rather than integer. The various parameters are just shifting factors rather than arbitrary scale factors. In the integer approach I used a multiplication while a shift might be more appropriate with a vector although I think the impact is more clear using the multiply. After all, it is implementing a formula... The issue is not if my math is good. The only question I have is whether there is a better way to express it in VHDL. BTW, I think I need parens around the stuff the mod is acting on, if nothing else a bit more clarity... RickArticle: 146395
Hi All I'm looking into the IP encryption that VHDL-2008 now offer's to use on our code. I've got the latest Ashenden book which has a small chapter on it, but was after other reference material and even working examples. My main query centers around how do you encrypt the code. Are there 3rd party tools? Modelsim PE does it, but assuming that I need to encrypt for Xilinx, Synplify, Altera(?), and even particular customers as well is Modelsim the best choice. It also seems funny that you need to run a simulator to encrypt source code. Also the session key for the assymetic encryption seems to be recorded into the file only when I'm using a digital envelope (and then hopefully it is encrypted). Does it make sense that it does not need to be recorded if you are not using a digital envelope? I also seem to be having issues using Modelsim's public key to encrypt the session key. In not including it in the code it appears to encrypt appropritely. Any help/suggestions would be great Andrew My protect code is as follows: `protect key_keyowner = "Mentor Graphics Corporation" `protect key_method = "rsa" `protect key_keyname = "MGC-VERIF-SIM-RSA-1" -- `protect key_public_key -- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnJfQb +LLzTMX3NRARsv7A8+LV5SgMEJCvI -- f9Tif2emi4z0qtp8E+nX7QFzocTlClC6Dcq2qIvEJcpqUgTTD+mJ6grJSJ +R4AxxCgvHYUwoT -- 80Xs0QgRqkrGYxW1RUnNBcJm4ZULexYz8972Oj6rQ99n5e1kDa/ eBcszMJyOkcGQIDAQAB `protect key_block `protect data_method = "aes128-cbc" `protect encoding = (enctype = "base64") `protect author = "IP Provider" `protect author_info = "Widget 5 version 3.2" `protect begin :::: :::: `protect end Generated file from Modelsim: `protect BEGIN_PROTECTED `protect encrypt_agent = "Model Technology", encrypt_agent_info = "6.5d" `protect key_keyowner = "Mentor Graphics Corporation" , key_keyname = "MGC-VERIF-SIM-RSA-1" , key_method = "rsa" `protect encoding = ( enctype = "base64" ) `protect KEY_BLOCK B3fAWX5ctfzZv7uO7JWDm8Zcg8uldFm4KpvG7JKaLjQffxULilmf0g4V111d4hxX K9DzyWhJJL+mJj00qs5molQQkKKUfW6oAkb2K1kcN1wPaWAZwRcZH8lOF/mOw4Xj Pc5529GuFsyEIb8HgjIf4w+qKDb0UGtbmmFbyYl06HA= `protect data_method = "aes128-cbc" `protect encoding = ( enctype = "base64" , bytes = 1770 ) `protect DATA_BLOCK :::::: :::::: `protect END_PROTECTEDArticle: 146396
On Mon, 15 Mar 2010 09:27:02 -0700, Rob Gaddi <rgaddi@technologyhighland.com> wrote: >On Mon, 15 Mar 2010 12:07:24 +0000 >Brian Drummond <brian_drummond@btconnect.com> wrote: > >> On Mon, 15 Mar 2010 02:51:22 -0700 (PDT), lolita grenoble >> <lolita.grenoble@gmail.com> wrote: >> >> >hello, >> >i need help. >> >i work over an algo in C langage that verifies a design described in >> >VHDL >> >for it, i want take all informations from my vhdl code for use them >> >in my programme in C and i don't know how. >> >> One way is to write a file in your VHDL code (running it in the >> simulator) then read that file in your C code. >> >> - Brian > >Specifically, your search term is STD.TEXTIO Indeed. You can write binary files (e.g. .bmp images) from VHDL but the details are not defined so the result is not necessarily portable. Modelsim is straightforward but Xilinx ISE Simulator is not. - BrianArticle: 146397
Hi, I need an information. I need to have an FPGA Board and recive from a adc working between 20MHz and 100MHz, but i don't have any idea who to do it because i don't know any site that sells this things together! Thanks for the attentionArticle: 146398
On Mar 15, 8:39=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > On Mar 13, 9:59=A0pm, GaLaKtIkUs=99 <taileb.me...@gmail.com> wrote: > > > I googled for s g.723.1 codec ipcore for xilinx FPGA but didn't find > > any :( > > Please help! > > > Mehdi > > I Googled for "Next Week's Winning Lotto Numbers" and didn't find > those either. > > Here's a couple of links for you: > <http://www.vhdl-online.de/tutorial/englisch/inhalt.htm> > <http://en.wikipedia.org/wiki/G.723.1> > > RK Thanks a lot! I didn't know such a thing like wikipedia! Further I'll always take a look there before asking stupid questions!!! Waaaaaaaaaaaah ... VHDL is really cool!! I'll move away from SystemVerilog. More seriously: Before asking I made some searches in major IP core providers, opensource community, of course I took a look in wikipedia. And I don't need courses of HDL since I have already an experience of 8 years!! :) One major reason why I'm looking for IPs is that I don't want to beggin long administrative procedures of paying for G.723.1 patents. The IP provider should have done this job!! :-) Any way I would like to thank you for the effort you made :-) -- MehdiArticle: 146399
Hi, The setup is the following : - a stratix II GX hosts a Nios IIe - one timer running continuously at a period of 1s, priority level 6, the handler for this interrupt has some functions calls to usleep and performs polling, this handler is made interruptible via the use of the alt_irq_interruptible and alt_irq_noninterruptible pair of functions - one hw interrupt generates an interrupt every 500 us with a prioity level 2 a uart running at 115 kbauds using the small driver implementation (no interrupt) - the main function of the C program is waiting forever for characters to come in via the uart and when a command is received it processes it and gets back to expecting a new command forever With this setup it seems that the uart does not work well. When I pause the program after noticing it does not respond the program is almost always located in the usleep function called from the low priority interrupt handler. Is there anything in the setup described that is bad design ? What am i missing ? All ideas are welcome ! Best regards, JF
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