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
This is actually a re-post of my thread on alteraforum.com. ( www.alteraforum.com/forum/showthread.php?t=39255&p=161811#post161811 ) Having got no answers I'll post here as well. Before anyone comments on this, I have searched the forum and read everything I have found on the internet with people getting this error message. I'll try to post as much relevant information as possible, so the next one who has this problem might get off a bit easier. "Error (209014): CONF_DONE failed to go high in device 1" The error message happens both when trying to program the Serial Flash Loader and when trying to program JTAG directly. The programming fails before there is any progress, it doesn't even say 0%. Auto Detect Device functions as it should though. I get the choice between EP4CE15 and EP3C16, but that has never been a problem with other designs. I have made a custom board with a FBGA256 Cyclone IV EP4CE15 fpga and some peripherals. The fpga is hooked up with JTAG for Serial Flash Loader (SFL) as described in the Device Handbook on page 218 (figure 8-29, revision november 2011). I'm using a 20MHz CMOS oscillator, although that shouldn't have any impact on this issue as far as I know. The supply voltages are derived through separate low-noise, high PSRR LDO-regulators which can deliver max 150mA each. They are connected as such: VCCIO of all IO-bank is 3,3V. VCCINT is 1,2V. VCCD_PLL and VCCA is 2,5V nCE (J3) is connected to ground. nStatus (F4), nConfig (H5) and CONF_DONE (H14) are all pulled to VCCIO by 10k resistors. MSEL are connected as MSEL0(H13)=2,5V, MSEL1(H12)=GND, MSEL2(G12)=GND. But since I'm using JTAG these would be overridden anyways. The JTAG plug is connected as such: 1 - TCK (pin H3), pulled to GND by 1k 2 - GND 3 - TDO (pin J4) 4 - 2,5V 5 - TMS (pin J5), pulled to VCCIO by 10k 6 - 2,5V 7,8 - N.C. 9 - TDI (pin H4), pulled to VCCIO by 10k 10 - GND Does anyone know anything I can try? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154876
>The supply voltages are derived through separate low-noise, high PSRR >LDO-regulators which can deliver max 150mA each. >They are connected as such: >VCCIO of all IO-bank is 3,3V. >VCCINT is 1,2V. >VCCD_PLL and VCCA is 2,5V > VCCD_PLL is actually 1,2V. >The JTAG plug is connected as such: >1 - TCK (pin H3), pulled to GND by 1k >2 - GND >3 - TDO (pin J4) >4 - 2,5V >5 - TMS (pin J5), pulled to VCCIO by 10k >6 - 2,5V >7,8 - N.C. >9 - TDI (pin H4), pulled to VCCIO by 10k >10 - GND Pin 6 is actually a N.C. as well. I have also tried pulling 5 and 9 to VCCA in stead with no effect. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154877
Things I have noticed: 1. DEV_OE and INIT_DONE are each connected to a LED to ground with 470ohm resistors. They light up for a moment when I click the program-button in the Device Programmer. They both give 3,3V. - When INIT_DONE lights up, this should mean that the FPGA has entered "User Mode". But what does it mean when it goes high for a moment and then low again? Might this be the registers initializing to a high value or something like that before configuration? More things I have tried: 2. Checking the box for Compressed Bitstream. No change. 3. Enabling device-wide output enable (DEV_OE) and reset (DEV_CLRn) as per suggestions in another thread. No change. 4. Disconnecting the LEDs on DEV_OE and INIT_DONE, suspecting they'd overload the output. No change. 5. Tried pulling CONF_DONE high by a 1k resistor instead of 10k. No change. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154878
ERROR:PhysDesignRules:368 - The signal <p<0>_OBUF> is incomplete. The signal is not driven by any source pin in the design. ERROR:PhysDesignRules:368 - The signal <p<1>_OBUF> is incomplete. The signal is not driven by any source pin in the design. ERROR:PhysDesignRules:368 - The signal <p<2>_OBUF> is incomplete. The signal is not driven by any source pin in the design. ERROR:PhysDesignRules:368 - The signal <p<3>_OBUF> is incomplete. The signal is not driven by any source pin in the design. ERROR:PhysDesignRules:10 - The network <p<0>_OBUF> is completely unrouted. ERROR:PhysDesignRules:10 - The network <p<1>_OBUF> is completely unrouted. ERROR:PhysDesignRules:10 - The network <p<2>_OBUF> is completely unrouted. ERROR:PhysDesignRules:10 - The network <p<3>_OBUF> is completely unrouted. ERROR:Bitgen:25 - DRC detected 8 errors and 5 warnings. Please see the previously displayed individual error or warning messages for more details. these are the errors i am getting while i am trying to run the ip core of multiplication on spartan 3e.its giving me output on ism(behavioral simulation) but giving these errors while i am trying to run it througf fpga.can someone help??Article: 154879
deepak wrote: > ERROR:PhysDesignRules:368 - The signal <p<0>_OBUF> is incomplete. The signal is > not driven by any source pin in the design. > ERROR:PhysDesignRules:368 - The signal <p<1>_OBUF> is incomplete. The signal is > not driven by any source pin in the design. > ERROR:PhysDesignRules:368 - The signal <p<2>_OBUF> is incomplete. The signal is > not driven by any source pin in the design. > ERROR:PhysDesignRules:368 - The signal <p<3>_OBUF> is incomplete. The signal is > not driven by any source pin in the design. > ERROR:PhysDesignRules:10 - The network <p<0>_OBUF> is completely unrouted. > ERROR:PhysDesignRules:10 - The network <p<1>_OBUF> is completely unrouted. > ERROR:PhysDesignRules:10 - The network <p<2>_OBUF> is completely unrouted. > ERROR:PhysDesignRules:10 - The network <p<3>_OBUF> is completely unrouted. > ERROR:Bitgen:25 - DRC detected 8 errors and 5 warnings. Please see the > previously displayed individual error or warning messages for more details. > > > these are the errors i am getting while i am trying to run the ip core of multiplication on spartan 3e.its giving me output on ism(behavioral simulation) > but giving these errors while i am trying to run it througf fpga.can someone help?? Apparently you have a top level output port p[3:0] that is not ever driven by the design. In older versions of ISE, any undriven output was tied to ground. Given that in a real piece of hardware, unintentionally undriven outputs could cause board-level problems if arbitrarily connected to ground, newer versions of ISE leave them unrouted and then you will fail design rule check (DRC) when you go to create the project. You need to either connect this output port to something in the design, or remove it. -- GaborArticle: 154880
On 2013-01-25, Dldatwyler@GMail.com sent: |---------------------------------------------------------------------------| |"I noticed this very old post about the "book". Is it to be published soon?| | | | | |On Wednesday, February 22, 2006 9:28:42 AM UTC-7, Ray Andraka wrote: | |> Stephen Craven wrote: | |> > Last summer mention was made of a DSP / FPGA book by Ray Andraka | |> > hitting the (online) shelves this fall: | |> > http://tinyurl.com/s4v5s | |> > | |> > Has this come to pass? | |> > | |> > Aside from Meyer-Baese's "Digital Signal Processing with Field | |> > Programmable Gate Arrays" book, which I found somewhat difficult to | |> > read, are there any other FPGA-specific DSP books out there? | |> > | |> > Thanks! | |> > Stephen | |> > | |> | |> No, unfortunately, I am still working on it, and my publisher (elsevier) | |> is sitting on my rather firmly to get it done. Only so many hours per | |> day. They have set a new deadline for me to have it to them by August | |> so that they can get it out in the fall." | |---------------------------------------------------------------------------| I was not aware of this book but I am aware of Ray Andraka and he is very competent. You could ask him yourself: WWW.Andraka.comArticle: 154881
On Jan 26, 11:23=A0pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org> wrote: > On 2013-01-25, Dldatwy...@GMail.com sent: > |------------------------------------------------------------------------= ---| > |"I noticed this very old post about the "book". Is it to be published so= on?| > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | > |On Wednesday, February 22, 2006 9:28:42 AM UTC-7, Ray Andraka wrote: =A0= =A0 =A0 ||> Stephen Craven wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > > |> > Last summer mention was made of a DSP / FPGA book by Ray Andraka =A0= =A0 =A0 | > |> > hitting the (online) shelves this fall: =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > |> >http://tinyurl.com/s4v5s=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | > |> > Has this come to pass? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | > |> > Aside from Meyer-Baese's "Digital Signal Processing with Field =A0 = =A0 =A0 =A0 | > |> > Programmable Gate Arrays" book, which I found somewhat difficult to = =A0 =A0| > |> > read, are there any other FPGA-specific DSP books out there? =A0 =A0= =A0 =A0 =A0 | > |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | > |> > Thanks! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > |> > Stephen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > |> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | > |> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0| > |> No, unfortunately, I am still working on it, and my publisher (elsevie= r) | > |> is sitting on my rather firmly to get it done. =A0Only so many hours p= er =A0 | > |> day. =A0They have set a new deadline for me to have it to them by Augu= st =A0 | > |> so that they can get it out in the fall." =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > |------------------------------------------------------------------------= ---| > > I was not aware of this book but I am aware of Ray Andraka and he is > very competent. You could ask him yourself: > WWW.Andraka.com I am afraid, many 2005 techniques, like, for example, cordix, distributed arithmetics, utilization of SRL16 for delay lines, are not relevant today, when even low end FPGAs have plenty of hard multipliers and embedded memory blocks.Article: 154882
I've learned to use Active HDL some time ago and never had too much trouble with it. But now it is not letting me use the waveform viewer in an effective way. I typically add all my signals once and then as I work on the design and recompile it uses the same signal on each iteration of the edit/compile/simulate cycle. Now it is deleting all my signals from the waveform every time I recompile. Seems it is related to using the "advanced waveform editor". I found a setting that says, "preserve signals when simulation is initialized". WTF? I guess if you are doing everything from a simulation batch file you just add these signals too, but what is the purpose of automatically deleting them by default or at all? I would think a batch file could easily delete any existing signals before creating its display. Sometimes I just don't get the mindset of the tool developers. RickArticle: 154883
> Now it is deleting all my signals from the waveform every time I > recompile. Seems it is related to using the "advanced waveform editor". This option has always infuriated me. Thanks for saying that the problem is the tool, not me.Article: 154884
I believe the "preserve" option was not even available after they first int= roduced the Advanced waveform viewer. I am going to guess that the reason t= hat signals were not preserved was related to a software implementation dif= ficulty, and had little to do with the "user experience"...Article: 154885
On 1/26/2013 4:27 PM, Michael S wrote: > On Jan 26, 11:23 pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org> > wrote: >> On 2013-01-25, Dldatwy...@GMail.com sent: >> |---------------------------------------------------------------------------| >> |"I noticed this very old post about the "book". Is it to be published soon?| >> | | >> | | >> |On Wednesday, February 22, 2006 9:28:42 AM UTC-7, Ray Andraka wrote: ||> Stephen Craven wrote: | >> >> |> > Last summer mention was made of a DSP / FPGA book by Ray Andraka | >> |> > hitting the (online) shelves this fall: | >> |> >http://tinyurl.com/s4v5s | >> |> > | >> |> > Has this come to pass? | >> |> > | >> |> > Aside from Meyer-Baese's "Digital Signal Processing with Field | >> |> > Programmable Gate Arrays" book, which I found somewhat difficult to | >> |> > read, are there any other FPGA-specific DSP books out there? | >> |> > | >> |> > Thanks! | >> |> > Stephen | >> |> > | >> |> | >> |> No, unfortunately, I am still working on it, and my publisher (elsevier) | >> |> is sitting on my rather firmly to get it done. Only so many hours per | >> |> day. They have set a new deadline for me to have it to them by August | >> |> so that they can get it out in the fall." | >> |---------------------------------------------------------------------------| >> >> I was not aware of this book but I am aware of Ray Andraka and he is >> very competent. You could ask him yourself: >> WWW.Andraka.com > > I am afraid, many 2005 techniques, like, for example, cordix, > distributed arithmetics, utilization of SRL16 for delay lines, are not > relevant today, when even low end FPGAs have plenty of hard > multipliers and embedded memory blocks. > I disagree in some cases, although multipliers are bountiful, relatively speaking. Many applications have no problem using up all the multipliers and still unsatisfied. Being able to calculate an arctan with a pipelined cordic is still relevant. Regards, ChrisArticle: 154886
On Sun, 27 Jan 2013 22:46:05 -0500 rickman <gnuarm@gmail.com> wrote: > I've learned to use Active HDL some time ago and never had too much > trouble with it. But now it is not letting me use the waveform viewer in > an effective way. I typically add all my signals once and then as I > work on the design and recompile it uses the same signal on each > iteration of the edit/compile/simulate cycle. > > Now it is deleting all my signals from the waveform every time I > recompile. Seems it is related to using the "advanced waveform editor". > I found a setting that says, "preserve signals when simulation is > initialized". WTF? I guess if you are doing everything from a > simulation batch file you just add these signals too, but what is the > purpose of automatically deleting them by default or at all? I would > think a batch file could easily delete any existing signals before > creating its display. > > Sometimes I just don't get the mindset of the tool developers. > > Rick In my college transistor circuits course, back shortly before the discovery of electricity, we were targetting -100dB THD, and verifying against a distortion analyzer. Look at it on a scope, sine wave. Look at it on the analyzer, nuthin'. Back and forth, over and over, for 10 minutes we couldn't get any results out of the distortion analyzer. Turned out to have a tiny button next to the BNC called "Input Disconnect". Or as we called it, the Broken button. Since then I've been amazed at how many designers of how many things have felt the need to include a Broken button. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154887
On 1/28/2013 12:16 PM, Rob Gaddi wrote: > On Sun, 27 Jan 2013 22:46:05 -0500 > rickman<gnuarm@gmail.com> wrote: > >> I've learned to use Active HDL some time ago and never had too much >> trouble with it. But now it is not letting me use the waveform viewer in >> an effective way. I typically add all my signals once and then as I >> work on the design and recompile it uses the same signal on each >> iteration of the edit/compile/simulate cycle. >> >> Now it is deleting all my signals from the waveform every time I >> recompile. Seems it is related to using the "advanced waveform editor". >> I found a setting that says, "preserve signals when simulation is >> initialized". WTF? I guess if you are doing everything from a >> simulation batch file you just add these signals too, but what is the >> purpose of automatically deleting them by default or at all? I would >> think a batch file could easily delete any existing signals before >> creating its display. >> >> Sometimes I just don't get the mindset of the tool developers. >> >> Rick > > In my college transistor circuits course, back shortly before the > discovery of electricity, we were targetting -100dB THD, and verifying > against a distortion analyzer. Look at it on a scope, sine wave. Look > at it on the analyzer, nuthin'. Back and forth, over and over, for > 10 minutes we couldn't get any results out of the distortion analyzer. > > Turned out to have a tiny button next to the BNC called "Input > Disconnect". Or as we called it, the Broken button. Since then I've > been amazed at how many designers of how many things have felt the need > to include a Broken button. > They charge extra for buttons on test gear, don't they... no matter how banal... I'm still struggling with this issue, but in a more limited scope. When I compile bad code in a way that causes the tool to get upset enough to forget what the top level module is, on fixing the problem and starting the simulation the waveform display any variables on display can't be found in the code and are deleted... stupid tools! I guess my real issue is that I had been using an older version of the tool and for whatever reason I'm pretty sure I wasn't allowed to use the "advanced" waveform viewer. Now that I am using the *advanced* viewer, I am finding that it is only advanced in some ways that I don't actually perceive. I guess it might be faster. The simulations seem to run a lot faster than with the old tool, but I'm comparing apples and oranges in terms of the project. This one is still pretty small and is only running at a quarter MHz. At least I am learning to not "upset* the tools. Otherwise they try to get revenge... spiteful tools! RickArticle: 154888
On 1/28/2013 9:34 AM, Christopher Felton wrote: > On 1/26/2013 4:27 PM, Michael S wrote: >> On Jan 26, 11:23 pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org> >>> >>> I was not aware of this book but I am aware of Ray Andraka and he is >>> very competent. You could ask him yourself: >>> WWW.Andraka.com >> >> I am afraid, many 2005 techniques, like, for example, cordix, >> distributed arithmetics, utilization of SRL16 for delay lines, are not >> relevant today, when even low end FPGAs have plenty of hard >> multipliers and embedded memory blocks. >> > > I disagree in some cases, although multipliers are bountiful, > relatively speaking. Many applications have no problem using > up all the multipliers and still unsatisfied. Being able > to calculate an arctan with a pipelined cordic is still > relevant. Yeah, and not all FPGA projects use gargantuan devices that dim the city when powered up. I am right by a nuclear power plant and I can hear the turbines groan when some of you guys run your designs. I'm currently working on a powerless design. It will be so low power it scavenges power from stray electrons, quanta and fields, maybe even thermal gradients. I could power it from the glow of some of the high end FPGA designs, or even the convection air currents! Yes, I think CORDIC is still useful, although I plan to do it with a table lookup... I can live with six bits out. RickArticle: 154889
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) >> Turned out to have a tiny button next to the BNC called "Input >> Disconnect". Or as we called it, the Broken button. Since then I've >> been amazed at how many designers of how many things have felt the need >> to include a Broken button. > They charge extra for buttons on test gear, don't they... no matter how > banal... I suppose, but more buttons means that marketing can advertize them as additional features. Reminds me of the hardest to find button on most oscilloscopes, the on/off button (or knob or ...). -- glenArticle: 154890
On 1/28/13 3:57 PM, rickman wrote: > On 1/28/2013 9:34 AM, Christopher Felton wrote: >> On 1/26/2013 4:27 PM, Michael S wrote: >>> On Jan 26, 11:23 pm, Paul Colin Gloster <Colin_Paul_Glos...@ACM.org> >>>> >>>> I was not aware of this book but I am aware of Ray Andraka and he is >>>> very competent. You could ask him yourself: >>>> WWW.Andraka.com >>> >>> I am afraid, many 2005 techniques, like, for example, cordix, >>> distributed arithmetics, utilization of SRL16 for delay lines, are not >>> relevant today, when even low end FPGAs have plenty of hard >>> multipliers and embedded memory blocks. >>> >> >> I disagree in some cases, although multipliers are bountiful, >> relatively speaking. Many applications have no problem using >> up all the multipliers and still unsatisfied. Being able >> to calculate an arctan with a pipelined cordic is still >> relevant. > > Yeah, and not all FPGA projects use gargantuan devices that dim the city > when powered up. I am right by a nuclear power plant and I can hear the > turbines groan when some of you guys run your designs. > > I'm currently working on a powerless design. It will be so low power it > scavenges power from stray electrons, quanta and fields, maybe even > thermal gradients. I could power it from the glow of some of the high > end FPGA designs, or even the convection air currents! > > Yes, I think CORDIC is still useful, although I plan to do it with a > table lookup... I can live with six bits out. > > Rick I agree as well, I imagine there are many low-power low resource designs. A good book on DSP in FPGAs will cover both ends of the spectrum. How to easily use up all the multiplier resources as well as all the neat little tricks to save resources/power. What I don't like in books like this is device specific information. Seems pointless to provide specific FPGA architectures (changes too often). Just need the generic view of the architecture not the specific slice organization, or optimization on device specific components, again it should talk in device generalities. Regards, ChrisArticle: 154891
On 28.01.2013 23:51, rickman wrote: > I'm still struggling with this issue, but in a more limited scope. When > I compile bad code in a way that causes the tool to get upset enough to > forget what the top level module is, on fixing the problem and starting > the simulation the waveform display any variables on display can't be > found in the code and are deleted... stupid tools! I remember it was loosing everything when (re)compiled a package.Article: 154892
If I had a nickel for every time I've heard throughout my career about this= or that technology no longer being relevant... Technology is like fashion: whatever is old will be new again someday, with= a new spin and a new relevance. Don't throw it away; just keep it in the b= ack of your closet, and you will be able to use it again. And for those tha= t missed it the first time around, the second-hand stores are always full o= f these still-useful articles from bygone times. I remember my college digital design coursework included implementing boole= an logic functions with multiplexers and decoders. Then PALs came along and= changed that to sum-of-products. Then FPGAs came along and changed it back= (pre-HDL). Then HDL came along and changed it again. The Cordic algorithms were not new when FPGAs came along. They were dusted = off from the ancient spells of the priests of the order of multiplierless m= icroprocessors and "pieces of eight". And those priests were probably taugh= t their craft by the wizards of relays and vacuum tubes. AndyArticle: 154893
On 1/29/2013 7:14 AM, valtih1978 wrote: > On 28.01.2013 23:51, rickman wrote: >> I'm still struggling with this issue, but in a more limited scope. When >> I compile bad code in a way that causes the tool to get upset enough to >> forget what the top level module is, on fixing the problem and starting >> the simulation the waveform display any variables on display can't be >> found in the code and are deleted... stupid tools! > > I remember it was loosing everything when (re)compiled a package. When I used the Active simulator before it would not delete signals from the waveform display no matter what. I would eventually notice that a signal was not showing a waveform, most likely because I had deleted the signal from the code, and remove it from the display. I can't say much about variables in the waveform viewer. I don't recall having any problems with them, but I've not typically used them a lot, at least I didn't have a lot of need to show their waveforms. I seem to be using them more now and for more "important" signals. My test benches are full of them and now I'm having these problems. I would consider using a macro to add everything to the waveform display, I think there is even a menu command to save the current waveform setup as a .do file. But only the variables seem to be lost now and only after starting the simulation. The .do file would have to start the simulation, stop it immediately, delete all signals from the waveform display, add them all back and then restart the simulation... really? There has to be a better way. RickArticle: 154894
On 1/29/2013 8:07 PM, rickman wrote: > On 1/29/2013 7:14 AM, valtih1978 wrote: >> On 28.01.2013 23:51, rickman wrote: >>> I'm still struggling with this issue, but in a more limited scope. When >>> I compile bad code in a way that causes the tool to get upset enough to >>> forget what the top level module is, on fixing the problem and starting >>> the simulation the waveform display any variables on display can't be >>> found in the code and are deleted... stupid tools! >> >> I remember it was loosing everything when (re)compiled a package. > > When I used the Active simulator before it would not delete signals from > the waveform display no matter what. I would eventually notice that a > signal was not showing a waveform, most likely because I had deleted the > signal from the code, and remove it from the display. > > I can't say much about variables in the waveform viewer. I don't recall > having any problems with them, but I've not typically used them a lot, > at least I didn't have a lot of need to show their waveforms. I seem to > be using them more now and for more "important" signals. My test benches > are full of them and now I'm having these problems. > > I would consider using a macro to add everything to the waveform > display, I think there is even a menu command to save the current > waveform setup as a .do file. But only the variables seem to be lost now > and only after starting the simulation. The .do file would have to start > the simulation, stop it immediately, delete all signals from the > waveform display, add them all back and then restart the simulation... > really? > > There has to be a better way. Ok, some of the mystery has been lifted. I found a way to automatically create a macro to add all your signals to the display, but it still didn't solve the problem. But while I was looking at the text in the macro file, I noticed that the path for the variables that were being lost contained a line number reference! When a variable is declared in a process, it is given a path name to that process. If you don't assign a label, it just uses a line number. When that line number changes, the path is no longer valid and the variables disappear! I often start off without labels on most objects in my code and add them later when I am tidying up. Now I see I need to add them up front. Heck, VHDL lets you label every concurrent statement in the code since they are all processes really. Not that there is a lot of need for that. I didn't see much of this before because I wasn't using variables so much. Actually, a number of variables just got the axe. Sometimes they need to be accessed outside of the process and sometimes I prefer to make them concurrent assignments when that works just as well. -- RickArticle: 154895
Rob Doyle wrote: > > I guess that it is just a design from another day - a whole lot less > synchronous than anything I've done in an FPGA before. > Yes, some PDP-10s were not rigidly clocked at all, so that when there were no carries from the ALU after a few ns, the operation was considered complete and the result stored. Really nasty way to design a machine! > I have enjoyed going back through that all. I even found my "Mick and > Brick" book. I'll probably do a VAX 11/780 next which also used > bit-sliced parts. No, not true. The 780 was all 74S chips (some LS on non-critical paths) but nothing LSI at all. The 730 and 750 used TI mask-programmed logic array parts. I actually read the print set of a 780 about 30 years ago and at one time knew the design pretty well. JonArticle: 154896
Jon Elson <jmelson@wustl.edu> wrote: (snip) >> I guess that it is just a design from another day - a whole lot less >> synchronous than anything I've done in an FPGA before. > Yes, some PDP-10s were not rigidly clocked at all, so that when there were > no carries from the ALU after a few ns, the operation was considered > complete and the result stored. Really nasty way to design a machine! >> I have enjoyed going back through that all. I even found my "Mick and >> Brick" book. I'll probably do a VAX 11/780 next which also used >> bit-sliced parts. > No, not true. The 780 was all 74S chips (some LS on non-critical paths) > but nothing LSI at all. The 730 and 750 used TI mask-programmed logic > array parts. I actually read the print set of a 780 about 30 years ago > and at one time knew the design pretty well. Story I knew from about 30 years ago was that the 730 was build from 2900 series parts. That was supposed to be related to H-float being included, (no extra charge) when it wasn't for the earlier models. So, H-float on the 730 was faster than the software emulation on the 750. (But then again, I never tried.) -- glenArticle: 154897
i have the same problem and i've followed the xilinx manual. Em domingo, 22 de janeiro de 2012 13h01min34s UTC-2, =E3=83=90=E3=82=B5=E3= =83=AD escreveu: > Hi all. >=20 > I'm T.Koyama. >=20 >=20 >=20 > I download ISE 13.4 and make IP Microblze mcs. >=20 > I could make IP and bitstream,and I make ELF file under SDK >=20 > So I will download to FPGA, but Error ocuuer. >=20 >=20 >=20 > Error meaaseg is "ERROR:Data2MEM:47 - Not all BitLanes in >=20 > ADDRESS_SPACE 'mb_mcs.lmb_bram' have BMM location constraints." >=20 >=20 >=20 > Do you know What happend. >=20 >=20 >=20 > T . Koyama.Article: 154898
Hello,
might not be a real FPGA question,
but I hope that some of you doing not only the hardware part
but also working with the Xilinx SDK.
I try to use the CAN controller on e ZedBoard under Linux.
I *think* that I have done the CAN_L and CAN_H routing correct
to the FMC connector. Now I read and write to the CAN controller registers.
It seems to be correct, if I look what I'm reading back.
BUT, nothing happens at the CAN lines at the FMC connector.
What am I missing?
Do I need special clock settings in some other register, not CAN.
Or What else has to be programmed in order to get the CAN working?
Best regards
Heinz
Article: 154899
Heinz-Jürgen Oertel <hj.oertel@t-online.de> writes:
> Hello,
> might not be a real FPGA question,
> but I hope that some of you doing not only the hardware part
> but also working with the Xilinx SDK.
> I try to use the CAN controller on e ZedBoard under Linux.
> I *think* that I have done the CAN_L and CAN_H routing correct
> to the FMC connector. Now I read and write to the CAN controller registers.
> It seems to be correct, if I look what I'm reading back.
> BUT, nothing happens at the CAN lines at the FMC connector.
> What am I missing?
> Do I need special clock settings in some other register, not CAN.
> Or What else has to be programmed in order to get the CAN working?
AFAIK, the Zedboard has no CAN physical layer on - how did you turn your
CAN Tx and Rx into CAN_H and CAN_L?
The CAN checklist goes:
* Have you got all the same "type" of PHY (there are high-speed,
low-speed, single-wire etc. variants)
* If high-speed, is the bus using twisted pair wiring?
* Is the bus a sensible length ("sensible" depends on bit-rate, wire
quality, and sundry other issues, so start with a small bus on the
bench ~2m)
* Is the bus terminated correctly?
* Have you another node on the bus to acknowledge the transmissions?
* Are all the nodes running with the same bit width and sampling point?
* Is the bus noise-free?
Do you have any CAN analysis tools (Canalyzer for example, or a
scope/logic analyser that understands the protocol)?
Cheers,
Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
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