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 Wed, 03 Sep 2008 13:43:44 -0600, Kevin Neilson <kevin_neilson@removethiscomcast.net> wrote: >Evan Lavelle wrote: >> On Wed, 3 Sep 2008 08:00:31 -0700 (PDT), tullio >> <tullio.grassi@gmail.com> wrote: >... >> >> The good news is that your RTL works.... >> >> Now get a Verilog netlist out of XST, and repeat the test with the >> netlist rather than 'test1.v'. If the test now fails, XST is broken. >> ... >If XST doesn't pass the test, that doesn't mean it is broken in this >case. An extracted FSM is not supposed to be identical to RTL. That is >the whole idea of FSM extractors. They take the RTL and recode it, >possible using a different encoding, and also removing logic related to >moving to a default state. You can turn off the extractor, but you >wouldn't want to. Can you back up the "also removing logic related to moving to a default state"? The original RTL is very specific; it describes what to do if the state is not 001, 010, or 100 (which, BTW, requires a tiny amount of logic). If the synthesiser doesn't do this, then it's broken. Specifying a global one-hot option (which, IIRC, is the default anyway) doesn't give the synth carte blanche to find any sequential case statements and to remove the default branch. Besides, how would XST know that this was an FSM anyway? If the docs are to be believed, it needs to find a state register which is reset, and (for Verilog) which is either "an integer or a set of defined parameters". None of these conditions are true in this case. Yes, if you have an identifiable state register, and you ask the synth to recode it, then you can get differences in pre- and post-synth simulation, *if* you expect specific values on your state register. But, if you want the synthesiser to recode, your simulation should be testing against enumerated or parameterised values anyway. That's not the problem the OP is seeing here; he thinks he's losing logic. Your counter example isn't relevant. Let's assume that the counters actually are identical, and the synthesiser can determine that it's impossible for either count1 or count2 to leave the range [0,135]. In this hypothetical case, the synthesiser is permitted to change the terminal count logic, *because the change is not observable*. The synthesiser can do anything it wants, as long as the simulation semantics of the original code is preserved, or you specifically request a change in semantics - register retiming, state register recoding, whatever. This is *not* true of the OP's case; the loss of logic - if it has actually happened - has changed the behaviour of the code. -EvanArticle: 134851
I'm working on a Spartan2 design which runs on a PCI card or a PCI Express card (through a PCI-express to PCI bridge chip). Besides the PCI express or PCI interface the design is almost the same for both boards. In some specific type of PCs (mostly server chassis) the design quits working right away or after a while. Some of the internal statemachines quit even when the option 'Safe implementation' is turned on. In most PCs (say 99.9%) the design works okay though. The timing is not very tight. The place&route report shows 8ns timing margin on the 33MHz PCI clock which also clocks the internal logic. So I suspect no problems there. On the PCI board the Spartan2 is powered by a LM1086 1.5A linear regulator, on the PCI Express board the Spartan2 is powered by the PC's 3.3V directly. Core power (2.5V) is provided by another LM1086 regulator. Bypassing consists of 4 4.7uf tantalum caps (2 for 2.5V and 2 for 3.3V) and about 10 100nf ceramic caps (0805 or 0603) again half for 3.3V and the other half for 2.5V. The PCB is a 4 layer board with power and ground planes. Someone already implemented some safeguards around the statemachines as a quick hack which seems to work. This more or less rules out corruption of the configuration bits. Any ideas where to look for? -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 134852
Nico Coesel wrote:
> In some specific type of PCs (mostly server chassis) the design quits
> working right away or after a while.
> Any ideas where to look for?
unregistered inputs
latch warnings
missing external timing constraints
-- Mike Treseler
Article: 134853On Sep 3, 12:10=A0am, Qingbo <qing...@gmail.com> wrote: > one can generate on a Virtex-5 device? > > Thanks, > Qingbo I would think that the number of available DLLs would be the limiting factor. That, and (as Brian mentioned) the number of I/O pins. G.Article: 134854
On Wed, 3 Sep 2008 09:18:32 -0700 (PDT), "jack.harvard@googlemail.com" <jack.harvard@googlemail.com> wrote: >On 3 Sep, 16:54, John_H <newsgr...@johnhandwork.com> wrote: >> On Sep 3, 7:21 am, "jack.harv...@googlemail.com"<jack.harv...@googlemail.com> wrote: >> >> <snip>> Dual-port RAM support is only for Virtex-2 Pro families and newer, and >> > is not intended for older devices. If you target one of the newer >> > devices, the correct type of RAM is inferred. >> >> <snip> >> >> What device are you working with? V2Pro is getting a bit long in the >> tooth by now. > >It's a Spartan3A. Which is younger than the V2Pro. The AR# you gave referred to the Spartan-2 family. You may still be in luck. But it's only worth pushing on that rope for so long. Then concede defeat; save time and instantiate the primitive component directly. - BrianArticle: 134855
On Wed, 03 Sep 2008 22:33:14 GMT, nico@puntnl.niks (Nico Coesel) wrote: >I'm working on a Spartan2 design which runs on a PCI card or a PCI >Express card (through a PCI-express to PCI bridge chip). Besides the >PCI express or PCI interface the design is almost the same for both >boards. > >In some specific type of PCs (mostly server chassis) the design quits >working right away or after a while. Some of the internal >statemachines quit even when the option 'Safe implementation' is >turned on. In most PCs (say 99.9%) the design works okay though. > >The timing is not very tight. The place&route report shows 8ns timing >margin on the 33MHz PCI clock which also clocks the internal logic. So >I suspect no problems there. Have you confirmed that the PCI clock is actually 33MHz? On some machines (mostly server motherboards) PCI can be switched to 66MHz (or 100 or 133 for PCI-X). I have observed a machine booting at 33MHz and switching to 66MHz during the BIOS startup (it was controllable via a BIOS setting). - BrianArticle: 134856
On Tue, 26 Aug 2008 15:24:49 -0700, Andrew FPGA wrote: > I can see how to get to 220MHz, but beyond that I don't > know. The longest carry chain is 10 bits. > Everybody is assuming an arithmetic counter with carrys, but that can be worked around. It's possible to implement the counter using something carry-less and very fast, e.g. a LFSR; the counting is a little complicated and has to be done offline (effectively it involves a discrete logarithm calculation, but it's doable for some LFSRs). I think the original application allows for calculating the target count offline. -- Przemek Klosowski, Ph.D. <przemek.klosowski at gmail>Article: 134857
Evan, XST isn't broken, and the FSM optimization is legit. In fact, every commercial FPGA synthesis tool (Synplify, Precision, QIS, XST, etc) will perform the same FSM optimization, unless explicitly instructed not to (typically by tagging the FSM as 'safe'). What we're looking at is called 'dead code elimination'. The synthesis tools performs a boolean reachability analysis on the state register. In the Verilog code, there is *no* assignment that ever assigns a value other than 001, 010, and 100 to the state register. Within the Verilog semantic, the state register will *never* reach any value other than these 3. The default clause is thus rightfully ignored and no 'recovery' logic is generated. As a matter of fact, in absence of SEUs, your design will *never* get into any other state than these 3. From a Verilog semantic standpoint, the RTL and the synthesized netlist are fully equivalent. One can certainly complain that the Verilog (and VHDL) semantic have no room for SEUs, but that's the way it is. Note that this optimization is orthogonal to the state encoding. Also, while this optimization is frequent for FSMs, it actually also applies to random logic, although the reachability analysis is often more difficult to perform. - gaelArticle: 134858
We had an issue with a "ground bounce" (Spartan3 design) in the bank containing the PCI-interface, which 'triggered' the asynchonous reset of the PCI-core... Do you use async resets ? /JochenArticle: 134859
Gael - I hadn't noticed the initial condition on the register, so I missed this; my apologies to X for casting aspersions. The OP's original question was "is there a more formal way to prove it [to confirm that the RTL and netlist are different]". In this case, he probably has to do it by simulation, since formal analysis is likely to show no difference, so the TB is still required to show that a transformation has taken place. Still, a useful reminder of the pitfalls of comparing pre- and post-synth results. -EvanArticle: 134860
Jon Beniston wrote: >> The choice of the GPL >> for the OpenSparc is similar - it effectively restricts its use to >> evaluation and academic work > > Not if they used the LGPL, it isn't. > They use the GPLv2, not the LGPL. One other point that I did not mention earlier for both GPL'ed code and LGPL'ed code is that it is perfectly possible to make and sell devices that use GPL'ed IP - as long as *all* the IP in the device is GPL'ed. I think it is very reasonable to say that the bitstream for a single FPGA device is a single "work", and that the license for that "work" is not affected by the licenses of any other "work", including other FPGA designs and software running on the FPGA, at least as long as you are talking about a complete design with a specific interface. Thus it is quite possible to use, for example, the OpenSparc commercially in an FPGA - as long as the rest of your code on the same device is also GPL'ed. When the GPL'ed IP already forms a major part of your design, this will make perfect sense. The trouble only comes if you want most of your design to have a closed source license, with only parts of it under the (L)GPL. The main difference between the LGPL and GPL is commonly summarised as saying that you can dynamically link code of any license with LGPL'ed code. You can't statically link non-(L)GPL'ed code with LGPL'ed code. This has been discussed and argued back and forth in the world of embedded software for years before it was a major topic in FPGA design, and the conclusion is that very few embedded software developers will touch LGPL'ed code unless they are happy with a completely open source program, or their system is large enough to support a more general OS with dynamic linking (such as an embedded Linux system) - for statically linked software, the LGPL and GPL are the same. Since placing and routing in an FPGA is directly equivalent to static linking in software, I can't see that there is any distinction between them. Some links showing other people's opinions on the use of the LGPL in embedded software: <http://lists.kde.org/?l=kde-policies&m=103813752610289&w=2> <http://listas.apesol.org/pipermail/sdl-libsdl.org/2006-January/053814.html>Article: 134861
On Wed, 03 Sep 2008 22:33:14 GMT, nico@puntnl.niks (Nico Coesel) wrote: >In some specific type of PCs (mostly server chassis) the design quits >working right away or after a while. Some of the internal >statemachines quit even when the option 'Safe implementation' is >turned on. In most PCs (say 99.9%) the design works okay though. Random data point from the mediaeval era: I had almost identical symptoms with a video processing card, about 15 years ago, in ISA bus. I eventually tracked it down to glitches on the bus reset line, so narrow that all the old-style ISA cards missed it, but the fast-ish FPGAs on my board would sometimes see it. I don't suppose it's the same issue for you. But it's weird how this kind of thing rears its head from time to time. -- 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: 134862
hi every body, Iam using EDK 9.2 in a small project for the uart , and i started the project with 100 mhz for the processor and 50 mhz for buses , and i want to change the frequency for the buses to 66 mhz , i did this before for 33 mhz , but in the case of 66 mhz nothing work, all i did i change the C_CLKDV_DIVIDE to 1.5 instead of 2 and the uart frequency to 66666667 instead of 50000000 and the c_plb_clk_period_ps to 14999 instead of 20000 , is there anything else i have to change thanks FATMAArticle: 134863
Evan, Formal verification (Logic Equivalence Checking) will indeed declare the RL and post-synthesis netlist equivalent. Simulation will also produce the same outputs, unless the state register is manually put into a 'illegal' state using a force command, as suggested and demonstrated by you and other posters. Unfortunately, these cases are only identifiable through log file inspection and schematic inspection. Synplify's log file specifically warns when others/default clause are ignored. In addition, Synplify features a message viewer with filtering capabilities. This allows thorough users to build once for all a filter that zooms in on important messages, without scrolling through hundreds of messages. I would also take the opportunity to suggest inserting a reset signal in this FSM. If it wasn't for the initial value, and its automatic translation to an INIT property by the synthesis tool, the FSM would most likely be stuck for ever... In general, I don't recommend relying on power-up initialization. Such implicit code is hardly portable, and incompatible with 'safe' designs; resolving a lock-up would require a complete power cycle, including configuration. I find the absence of reset in this FSM paradoxal since the original poster was concerned with illegal state arising from SEUs ;~) - gaelArticle: 134864
> > Not if they used the LGPL, it isn't. > > They use the GPLv2, not the LGPL. Yep - my mistake. > The main difference between the LGPL and GPL is commonly summarised as > saying that you can dynamically link code of any license with LGPL'ed > code. =A0You can't statically link non-(L)GPL'ed code with LGPL'ed code. > This has been discussed and argued back and forth in the world of > embedded software for years before it was a major topic in FPGA design, > and the conclusion is that very few embedded software developers will > touch LGPL'ed code unless they are happy with a completely open source > program, or their system is large enough to support a more general OS > with dynamic linking (such as an embedded Linux system) - for statically > linked software, the LGPL and GPL are the same. =A0Since placing and > routing in an FPGA is directly equivalent to static linking in software, > I can't see that there is any distinction between them. So partial reconfiguration in an FPGA to load the the LGPLed code would be ok? JonArticle: 134865
I am trying to use XST to create a "black box" from a VHDL core. The output NGC file fails when I try to include it in a Xilinx ISE design. Does anyone know the way to create a black box from a file.vhd? best regards.Article: 134866
Thanks to all answers. I had never appreciated that the verilog default clause is ignored unless I turn on the "safe" synthesis option. So in fact I don't need to prove that the machine does not recover from illigal states, because recovering is not guaranteed without "safe" option. Maybe the last comment from Gael is the most relevant to my case. In fact in the real hardware I observe a mis-behavior compatible with an illigal state immediately after FPGA configuration (about 1 time in 600 cycles), as if the initial value is not set properly. I often have FSMs that don't need any external reset and I have not coded it to save resouces. I guess I will either add a reset and/or explicitly code the unwanted states as suggested by Jim. I'll post the results. Tullio On 4 sep, 10:37, gael.p...@gmail.com wrote: > ... > > I would also take the opportunity to suggest inserting a reset signal > in this FSM. If it wasn't for the initial value, and its automatic > translation to an INIT property by the synthesis tool, the FSM would > most likely be stuck for ever... In general, I don't recommend relying > on power-up initialization. Such implicit code is hardly portable, and > incompatible with 'safe' designs; resolving a lock-up would require a > complete power cycle, including configuration. I find the absence of > reset in this FSM paradoxal since the original poster was concerned > with illegal state arising from SEUs ;~) > > - gaelArticle: 134867
Tullio, > I had never appreciated that the verilog default clause > is ignored unless I turn on the "safe" =A0synthesis option. This statement is too broad. I would modify it by saying that "unreachable default clauses are ignored by synthesis tools". If the default clause is part of an FSM, then one can force the synthesis tool to implement recovery logic by tagging the FSM as 'safe' (exact syntax varies from tool to tool). The actual recovery circuitry will vary from tool to tool, but in most cases it will put the FSM back into its reset/initial state. Note that this still does *not* implement the actual default clause (which could point to any legal state, and possibly set some output indicating an SEU has happened). To implement the actual default clause, you would need to: - use an enumerated type for the state vector, explicitly declaring all illegal states (the numer of which will depend on the desired encoding scheme) - turn off FSM extraction (locally or globally) - for some tools, set an attribute that disables sequential optimization for the state register > So in fact I don't need to prove that the machine does not recover > from illigal states, because recovering is not guaranteed without > "safe" option. Correct. > Maybe the last comment from Gael is the most relevant to my case. In > fact in the real hardware I observe a mis-behavior > compatible with an illigal state immediately after FPGA configuration > (about 1 time in 600 cycles), as if the initial value is not set > properly. > I often have FSMs that don't need any external reset and I have not > coded it to save resouces. > I guess I will either add a reset and/or explicitly code the unwanted > states as suggested by Jim. So, your search for recovery logic was in fact a workaround for a hardware misbehavior. Adding a reset will surely resolve your problem. I guess your intermittent problem demonstrates that power-up initialization is not 100% reliable. - gaelArticle: 134868
"tullio" <tullio.grassi@gmail.com> wrote in message news:e8e8899d-614f-4021-ab60-056545c3d260@b30g2000prf.googlegroups.com... > So in fact I don't need to prove that the machine does not recover > from illigal states, because recovering is not guaranteed without > "safe" option. As pointed out previously though, 'recovery' is usually hiding a symptom of the real underlying problem and even if the state machine 'recovers' the things that depend on it may not. > In > fact in the real hardware I observe a mis-behavior > compatible with an illigal state immediately after FPGA configuration > (about 1 time in 600 cycles), as if the initial value is not set > properly. This is a timing problem, the most likely cause is a setup time violation on some input relative to the clock when you're coming out of reset. For example, what do you have in your design to protect you for when the part finishes configuration? The end of configuration is generally totally asynchronous to any free running oscillator clock input that you may have to the design. Unless the input clocks to the design are stopped during and slightly after configuration it is darn near impossible to bring the part reliably out of configuration and into a working state. That's the reason that the first task of the design is to generate a synchronized internal reset to the rest of the design and THEN start doing it's thing. 1 in 600 failures is almost always a symptom of timing problems, find that to fix your design. The other possible cause of such seemingly random function is power supply issues. > I often have FSMs that don't need any external reset and I have not > coded it to save resouces. It's a false savings...and this design is an example of why that is. > I guess I will either add a reset and/or explicitly code the unwanted > states as suggested by Jim. I'd suggest getting to the root cause of your design issue (it's not whether the state machine is 'safe' or not), it's most likely timing and the lack of a synchronized reset. Otherwise, you're just guessing and coming to incorrect conclusions that 'seem' to work this time but will fail you next time (just like the way that the lack of designing in a reset as a general practice has failed you on this design). Good luck, Kevin JenningsArticle: 134869
On Thu, 4 Sep 2008 02:24:50 -0700 (PDT), Pablo <pbantunez@gmail.com> wrote: >I am trying to use XST to create a "black box" from a VHDL core. The >output NGC file fails when I try to include it in a Xilinx ISE design. >Does anyone know the way to create a black box from a file.vhd? > >best regards. First thing to check is that the output NGC file was synthesised without I/O buffers on its internal ports. There are synthesis options for this. That would certainly cause it to fail when included in another design... - BrianArticle: 134870
Jon Beniston wrote: >>> Not if they used the LGPL, it isn't. >> They use the GPLv2, not the LGPL. > > Yep - my mistake. > >> The main difference between the LGPL and GPL is commonly summarised as >> saying that you can dynamically link code of any license with LGPL'ed >> code. You can't statically link non-(L)GPL'ed code with LGPL'ed code. >> This has been discussed and argued back and forth in the world of >> embedded software for years before it was a major topic in FPGA design, >> and the conclusion is that very few embedded software developers will >> touch LGPL'ed code unless they are happy with a completely open source >> program, or their system is large enough to support a more general OS >> with dynamic linking (such as an embedded Linux system) - for statically >> linked software, the LGPL and GPL are the same. Since placing and >> routing in an FPGA is directly equivalent to static linking in software, >> I can't see that there is any distinction between them. > > So partial reconfiguration in an FPGA to load the the LGPLed code > would be ok? > That would be fine, as far as I can tell. The idea is that the end user should be able to get hold of the source code for the LGPL'ed part, modify it (or get an updated version), and use that modified version in the complete system. If you can arrange for that to be possible using partial reconfiguration, that should be okay.Article: 134871
David Brown wrote: > Petter Gustad wrote: >> Why does Quartus run with lowest priority level (19) under Linux? It >> also seems like if you nice quartus_sh to some higher priority when >> you start it the sub-processes (like qartus_map etc) will still have >> priority 19. I find this a little odd. Is there a reason for this? >> > > I'd imagine the idea is that you can continue working with other > programs while the long-running processes run in the background. Modern > Linux kernels typically have schedulers that automate this (giving > higher priority to short-running interactive processes), but there is no > harm in running something like Quartus at low priority unless you are > simultaneously running another process that tries to use all available > processing time. It really hurts you if you have server machines with "cycle-scraper" processes (often verification jobs) that administratively have lower priority than Quartus. You want to be able to control this behaviour. -hpaArticle: 134872
MikeWhy (boat042-nospam@yahoo.com) wrote: : <randomdude@gmail.com> wrote in message : news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com... : > My main idea at the moment is an encrypting DIMM module, intended to : > protect against 'cold boot' attacks, and the scenario that an attacker : > is presented with a freshly-turned-off machine with some juicy secret : > still in a DIMM module, which they can then remove, throw in to some : > socket, and dump. : Perhaps the first order of business is to establish that this is a viable : attack. Can someone really do that? SDRAM refresh cycles are on the order : of <10 usec, otherwise data would be lost. I would think much simpler and : more severe "attacks" would be available once you gained physical control of : the machine. Cutting out the living and still beating heart idea tops them : all in complexity. SDRAM can last a surprisingly long time - I have a board that stores an image in some, and if you turn it off for a few mins and turn it back on, the image is still recognisable - if badly corrupted. Corruption starts within microsecconds but isn't instant or total. Regards ChrisArticle: 134873
On Sep 3, 5:01=A0pm, Marvin <marvin....@gmail.com> wrote: > Svenn, > > Try using SmartGuide for incremental place and route. > > http://toolbox.xilinx.com/docsan/xilinx9/help/iseguide/html/ise_using... > > On Sep 2, 10:09=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > > > > > Svenn Are Bjerkem wrote: > > > In a fairly large design I am doing some debugging on the system boar= d > > > directly. When I discover a mistake and modify the vhdl code, the > > > whole design goes through synthesis and place-and-route. Many parts o= f > > > the design are never touched by my modifications, and I wonder if it > > > is possible to speed up the debug-modify-compile > > > I finish the debug-modify-compile loop in simulation. > > Even though simulation requires significant time on the front end, > > debugging typos and changes is quick and straightforward. > > > =A0 =A0 =A0 =A0-- Mike Treseler- Hide quoted text - > > - Show quoted text - SmartGuide might work for you but using partitions is a better approach - SmartGuide does not always work and the tool can redo P&R for all the modules since it just uses the previous run as a guide...Article: 134874
KJ wrote:
> As pointed out previously though, 'recovery' is usually hiding a symptom of
> the real underlying problem and even if the state machine 'recovers' the
> things that depend on it may not.
Yes. That is the main point.
I would call this attribute "clean" rather than "safe".
A counter is "safe" in the sense that
any forced value will eventually be returned to zero.
But that doesn't mean that a controller
waiting on some count will work acceptably
in the event of such an upset.
As Kevin explains, if this upset is happening
on the bench, a design error is a more
likely cause than gamma rays.
-- Mike Treseler
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