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
Venkat wrote: > Hello all, > > I have a question regarding migration of design from Xilinx FPGA to > ASIC. There are lot of Xilinx IP Cores(I am sure even Altera will have > too) which are commonly used for Arithmetic Purposes. For instance my > design uses the Xilinx FFT/IFFT IP Cores and if the design has to be > moved to the ASIC at later stages, can Xilinx Provide the netlist for > ASIC technology as well? > > I hope I put down my query clearly and will be glad to receive > responses. > This isn't answering your question, but I personally have very good experience with the Altera HardCopy FPGA to ASIC migration program. It allows you to have an ASIC which is pin compatible, using the same drivers etc, all out of a single toolchain. We used it at a former employer of mine. -hpaArticle: 136851
On Mon, 8 Dec 2008 16:50:08 -0800 (PST), Venkat <venkat.japan@gmail.com> wrote: >Hello all, > >I have a question regarding migration of design from Xilinx FPGA to >ASIC. There are lot of Xilinx IP Cores(I am sure even Altera will have >too) which are commonly used for Arithmetic Purposes. For instance my >design uses the Xilinx FFT/IFFT IP Cores and if the design has to be >moved to the ASIC at later stages, can Xilinx Provide the netlist for >ASIC technology as well? Xilinx very clearly states that any IP they give you is for their devices only. I'm not sure what their policy is for licensing source of their IP for ASIC porting. Obviously they can provide the source but whether they do is another question. You may have to find other sources to replace the IP blocks you used when you need to do ASIC porting. Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 136852
Venkat wrote: > I have a question regarding migration of design from Xilinx FPGA to > ASIC. There are lot of Xilinx IP Cores(I am sure even Altera will have > too) which are commonly used for Arithmetic Purposes. For instance my > design uses the Xilinx FFT/IFFT IP Cores and if the design has to be > moved to the ASIC at later stages, can Xilinx Provide the netlist for > ASIC technology as well? The only sane way to design is to use 3rd party IP that can be ported to ASIC or design the IP yourself. Xilinx will not give you the IP for ASIC porting. It might not be even very suitable for that because it is partly full custom hard IP partly soft IP. Maybe if you have deep enough pockets and big enough company behind you might get some deal, but I wouldn't count on it. If the FPGA is only a prototyping vechile before ASIC, the design should be done for the ASIC and ported to FPGA. The FPGA port will be suboptimal, it might require a big FPGA, low clock frequency etc. but can be used for prototyping. Vendor specific IP cores are a way to force the user to use one FPGA architecture, and also force to it in the future if the designs are updated etc. --KimArticle: 136853
On Dec 8, 11:14=A0pm, "lecroy7...@chek.com" <lecroy7...@chek.com> wrote: > I have this happen all the time with ISE. =A0The problem seems to be > something with their database. =A0You can reload a known good project > and ISE can't build it. =A0 =A0The other problem you may run into is that > even though ISE will give a message that it built the project just > fine, the actual output files will not get updated. > > Solution, blow away all the temp files. [...] Thank you lecroy, I got a similar answer on the xilinx forums, I just finished cleaning everything in the TEMP directory. Now ISE is working 'fine' again :-) > Hope this helps. It helped, thanks.Article: 136854
On Dec 8, 8:35=A0pm, Gabor <ga...@alacron.com> wrote: > It sounds like Mike means the 10.1 problems. =A0It would be > good to have your project synthesizable in the better > tool version. =A0Maybe you can try 10.1 again and post > some of the error messages here... Yes I'd like to have my project synthesizable on new software too. But I cannot test intensively, 10.1 Webpack doesn't support the FPGA I'm using (xc4vfx-60) so I used a registered copy of a friend of mine to test the project. > By the way, I've been using Xilinx tools for a very long > time, and I think the real shoddy software start at the > release of version 7. =A0In my opinion it continued on a > downward spiral through 9.2 and now it's getting a bit > better again. =A0I still have version 6.1i which I use for > any device old enough to be supported by it. =A0It rarely > crashes and the project file is editable text. > > Those were the days... I agree with you, I started used Xilinx tools with the release 7 ... :- DArticle: 136855
On Mon, 8 Dec 2008 11:41:36 -0800 (PST), Gabor wrote: >The bidirectional case is interesting in that it crops up >in VHDL as well. It's even worse in VHDL, because there is no really good way to model a bidi link even for simulation in VHDL. (Yes, I know about the models on Ben Cohen's website, but they have significant limitations.) At least Verilog has its tran and tranif primitives, allowing true bidi connection modelling. >You would think that synthesis would have some sort of bidirectional >connection It might be worth checking out whether any real tools support "tran". I breezily said they don't, but on reflection I'm not so sure. It would be very easy for synthesis to implement tran as a simple alias, I suspect. Interestingly, VHDL _does_ have true bidi connection (net collapsing): connection across a port boundary. The signals inside and outside the entity are merged and become one and the same net. It doesn't help to solve the current problem, though. -- 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: 136856
On Dec 8, 9:54=A0pm, benwan...@gmail.com wrote: > Hi, > I read reports that DDR3 can work at 400 MHz with FPGAs. Can DDR do > the same? > Thanks, Hi, Woulden't count on it, why use an "old" memory technology when you can run DDR2 at 400MHz and DDR3 at 533MHz. just my 0.02$ /FredrikArticle: 136857
On Dec 8, 9:54=A0pm, benwan...@gmail.com wrote: > Hi, > I read reports that DDR3 can work at 400 MHz with FPGAs. Can DDR do > the same? > Thanks, Sorry just read the text and not the header. According to Xilinx marketing V5 can run DDR2 at 400MHz. /FredrikArticle: 136858
On Dec 9, 3:42=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
>
> Interestingly, VHDL _does_ have true bidi connection
> (net collapsing): connection across a port boundary.
> The signals inside and outside the entity are merged
> and become one and the same net. =A0It doesn't help to
> solve the current problem, though.
> --
The current problem of flipping the bit numbering does get handled in
VHDL with port mappings, example below.
Kevin Jennings
-- start of sample code
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity foo is
port(
Bidi: inout std_logic_vector(0 to 7));
end foo;
architecture RTL of foo is
begin
Bidi <=3D (others =3D> 'Z');
end RTL;
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity foo_foo is
end foo_foo;
architecture RTL of foo_foo is
signal xyz: std_logic_vector(7 downto 0);
begin
xyz <=3D "11110000", "00001111" after 10 ns, "10101010" after 20 ns;
The_Foo: entity work.foo port map(Bidi =3D> xyz);
end RTL;
-- end of sample code
Article: 136859KJ schrieb: > On Dec 9, 3:42 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: >> Interestingly, VHDL _does_ have true bidi connection >> (net collapsing): connection across a port boundary. >> The signals inside and outside the entity are merged >> and become one and the same net. It doesn't help to >> solve the current problem, though. >> -- > > The current problem of flipping the bit numbering does get handled in > VHDL with port mappings, example below. > > Kevin Jennings > > -- start of sample code > library ieee; > use ieee.std_logic_1164.all; > use ieee.numeric_std.all; > > entity foo is > port( > Bidi: inout std_logic_vector(0 to 7)); > end foo; > architecture RTL of foo is > begin > Bidi <= (others => 'Z'); > end RTL; > > library ieee; > use ieee.std_logic_1164.all; > use ieee.numeric_std.all; > > entity foo_foo is > end foo_foo; > architecture RTL of foo_foo is > signal xyz: std_logic_vector(7 downto 0); > begin > xyz <= "11110000", "00001111" after 10 ns, "10101010" after 20 ns; > The_Foo: entity work.foo port map(Bidi => xyz); > end RTL; > -- end of sample code Doing this can cause real headaches. I had some trouble with this kind of inversion before. In the simulation everything is fine because the simulator handles the inverting correctly. If you synthesize both modules independently with XST and link them later on with ngdbuild, the following happens: Ngdbuild apparently does not handle the signal as a bus; instead it connects the port one-by-one Bidi<0> to xyz<0> etc. ... Your simulation is ok, but the real behaviour becomes nonsense.Article: 136860
On Dec 6, 2:17=A0am, xilinx_user <barri...@ix.netcom.com> wrote: > I am using ISE Webpack 10.1 along with the lite version of the > simulator. I can't seem to figure out how to save signals I added to > the waveform viewer so that I can use the same signal set at a future > time. > > I know this is a naive question, but I have been away from the tools > for some time and need to come back up to speed. I am very new to ISIM. I am running the latest patches with the full version of ISE but the evaluation version of ISIM. I have a couple of comments on what you wrote. First, when I add waveforms to the viewer, they stick. It used to mangle them and remove them but since I loaded all of the patches I have not seen it do this. Second, there appears to be a problem if you use Dividers and Groups. If I used the same name for both, it seems to cause problems. I would see waveforms not stick and things would get rearranged. I can not tell you 100% that this was the fix, however after makeing all names unique, these problems have cleared up. Third, I suspect using std.textio.all is causing some problems. Last, there seems to be a huge difference between what you can do between Behavioral and Post-Route. I tried to purchase an upgrade to ISE to include ISIM but Avnet has quoted just shy of $3000! That's an upgrade BTW, not a full new license! It took over a month just to get the quote from them. So for now, I can't tell you that if you purchase the full version of ISIM that the Post-Route limitations would improve. From what I have seen of ISIM, I would not put too much stock into it just yet. No code coverage. No support for 64-bit OS (you have to have both versions installed on your 64-bit system, then run the 32- bit ISE to get ISIM). Limited documentation and pretty much a total lack of support. Not to mention the bugs. IMO, not worth the upgrade price. It does sound like version 12 of the tools may be a good time to jump in.Article: 136861
Kim Enkovaara wrote: > Vendor specific IP cores are a way to force the user to use one FPGA > architecture, and also force to it in the future if the designs are > updated etc. I agree. Using a device specific core, or even a primitive, is a gamble. My best odds to keep control of a design for verification, maintenance and portability, is to own the source code. -- Mike TreselerArticle: 136862
On Dec 9, 1:38=A0am, fredrik_he_l...@hotmail.com wrote: > On Dec 8, 9:54=A0pm, benwan...@gmail.com wrote: > > > Hi, > > I read reports that DDR3 can work at 400 MHz with FPGAs. Can DDR do > > the same? > > Thanks, > > Sorry just read the text and not the header. According to Xilinx > marketing V5 can run DDR2 at 400MHz. > /Fredrik In the user's guide UG086 for the latest version of MIG (v2.3), table 9-1 states that the fastest design frequency is 333.Article: 136863
On Dec 8, 1:39=A0pm, Gabor <ga...@alacron.com> wrote: > On Dec 8, 3:24=A0pm, Digi Suji <digis...@gmail.com> wrote: > > > > > Hi, > > > I am trying to do post-translate simulation on Xilinx ISE 10.1 on a PC > > (Win XP). When I try to compile the UNISIM/SIMPRIM libraries, the > > system asks for 3rd party simulators. So I installed Model Sim PE > > student edition. I am again stuck because my design is bigger than > > ModelSim Student Edition would handle. > > > My school has NC-Verilog on UNIX machines. Is there any way that I can > > compile, UNISIM/SIMPRIM libraries on PC for NC-Verilog simulator(NC- > > Verilog is on UNIX). When I try to compile, I get a message ncsim > > executable is not found because there is no NC-Verilog installed on > > PC. > > > Can any one please suggest how can I get through this phase? > > > Thanks. > > The "compxlib" process in ISE actually calls ModelSim (or other > third party software) to do the compilation. =A0The library sources > are in the Xilinx ISE installation tree, though. =A0So you could > compile them directly on your UNIX box. =A0If you have a log from > compiling the libraries for ModelSim PE Student edition, you > can see where the source files are. =A0It is also possible that > ISE created a script for ncsim that you can directly use on the > UNIX box. Hi Gabor, The problem I have is I do not have Xilinx installed on my school UNIX box and ncsim is not on my windows box. Both are on the different system. I tried using "compxlib" on UNIX and obviously the system says "no command" because I do not have XILINX on the unix box do you have any solution for me? ThanksArticle: 136864
Thank you all. My understanding is Virtex-5 is able to run DDR2 at 400MHz, and they may've even even done that in their lab, but no released products support it. Am I right? Fredrick, can you point me to a link stating that V5 can run DDR2 at 400MHz? Thanks again. Ben, On Dec 9, 1:38 am, fredrik_he_l...@hotmail.com wrote: > On Dec 8, 9:54 pm, benwan...@gmail.com wrote: > > > Hi, > > I read reports that DDR3 can work at 400 MHz with FPGAs. Can DDR do > > the same? > > Thanks, > > Sorry just read the text and not the header. According to Xilinx > marketing V5 can run DDR2 at 400MHz. > /FredrikArticle: 136865
On Dec 9, 4:55=A0pm, Digi Suji <digis...@gmail.com> wrote: > On Dec 8, 1:39=A0pm, Gabor <ga...@alacron.com> wrote: > > > > > On Dec 8, 3:24=A0pm, Digi Suji <digis...@gmail.com> wrote: > > > > Hi, > > > > I am trying to do post-translate simulation on Xilinx ISE 10.1 on a P= C > > > (Win XP). When I try to compile the UNISIM/SIMPRIM libraries, the > > > system asks for 3rd party simulators. So I installed Model Sim PE > > > student edition. I am again stuck because my design is bigger than > > > ModelSim Student Edition would handle. > > > > My school has NC-Verilog on UNIX machines. Is there any way that I ca= n > > > compile, UNISIM/SIMPRIM libraries on PC for NC-Verilog simulator(NC- > > > Verilog is on UNIX). When I try to compile, I get a message ncsim > > > executable is not found because there is no NC-Verilog installed on > > > PC. > > > > Can any one please suggest how can I get through this phase? > > > > Thanks. > > > The "compxlib" process in ISE actually calls ModelSim (or other > > third party software) to do the compilation. =A0The library sources > > are in the Xilinx ISE installation tree, though. =A0So you could > > compile them directly on your UNIX box. =A0If you have a log from > > compiling the libraries for ModelSim PE Student edition, you > > can see where the source files are. =A0It is also possible that > > ISE created a script for ncsim that you can directly use on the > > UNIX box. > > Hi Gabor, > > The problem I have is I do not have Xilinx installed on my school UNIX > box and ncsim is not on my windows box. Both are on the different > system. I tried using "compxlib" on UNIX and obviously the system says > "no command" because I do not have XILINX on the unix box > > do you have any solution for me? > > Thanks I assume you have a way to transfer files from your PC to the UNIX machines at school? You would need to do this for your source code anyway. The library sources are in your Xilinx ISE installation tree on your PC. On my PC they are in: E:\Xilinx\10.1\ISE\verilog\src\simprims E:\Xilinx\10.1\ISE\verilog\src\unisims E:\Xilinx\10.1\ISE\vhdl\src\simprims E:\Xilinx\10.1\ISE\vhdl\src\unisims Where E:\Xilinx\10.1\ISE is my ISE installation directory. You could zip these up and move them to the UNIX machine. Depending on what you are simulating you may not need all of the sources in these directories, but all that compxlib does is to compile all the sources in these directories and install them in four libraries: simprims_ver unisims_ver simprims unisims respectively for the four file sets. You would also need the XilinxCoreLib libraries which are structured similarly under your installation tree, if you use any coregen cores. If your project is small and you're not running a post translate simulation, it is quite probable that you only need a handful of these files. You could see what they are by watching error messages and add the sources to your work directory one by one, if you don't want to go through the complete library build process. HTH, GaborArticle: 136866
Hi group,
I have a clock coming into my FPGA driving a synchronous state machine.
My investigation would lead me to believe that there is a
spurious edge which my SM reacts to, thus causing erroneous data to be
latched.
I want to sample the clock and verify that the pulse I'm seeing is a
true pulse. I'm thinking about something simple like making sure the
incoming pulse is high for 3 or 4 sample clock periods and if so just
pass the clock through. My implementation would shift in the sampled
clock and the result of that shift register would gate the incoming clock.
Any thoughts?
Thank you,
Rob
Article: 136867On Dec 9, 8:46=A0pm, Rob <buz...@leavemealone.com> wrote: > Hi group, > > I have a clock coming into my FPGA driving a synchronous state machine. > =A0 =A0 =A0 =A0My investigation would lead me to believe that there is a > spurious edge which my SM reacts to, thus causing erroneous data to be > latched. > > I want to sample the clock and verify that the pulse I'm seeing is a > true pulse. =A0I'm thinking about something simple like making sure the > incoming pulse is high for 3 or 4 sample clock periods and if so just > pass the clock through. =A0My implementation would shift in the sampled > clock and the result of that shift register would gate the incoming clock= . > > Any thoughts? > That would be a waste of time. The clock is coming into the FPGA so you should verify that it is good using an oscilloscope. No matter what you found out if you were to implement some sort of filter as you described you would still need to validate that the clock *really* is doing something odd. Once you've done that the proper solution is to fix the glitch in the clock, not try to filter it. The other thing is to simply re-check your state machine logic. The most common cause for a timing failure is setup time violations. Every state machine input needs to be driven by logic that is clocked by that same clock signal. Any input that is not will eventually cause a state machine to do something unusual with nearly 100% certainty. What symptoms were you seeing that led you to believe that a spurious clock was the culprit and what is your rationale for ruling out setup or hold time violations or crossing clock domains? Kevin JenningsArticle: 136868
KJ wrote: > On Dec 9, 8:46 pm, Rob <buz...@leavemealone.com> wrote: >> Hi group, >> >> I have a clock coming into my FPGA driving a synchronous state machine. >> My investigation would lead me to believe that there is a >> spurious edge which my SM reacts to, thus causing erroneous data to be >> latched. >> >> I want to sample the clock and verify that the pulse I'm seeing is a >> true pulse. I'm thinking about something simple like making sure the >> incoming pulse is high for 3 or 4 sample clock periods and if so just >> pass the clock through. My implementation would shift in the sampled >> clock and the result of that shift register would gate the incoming clock. >> >> Any thoughts? >> > > That would be a waste of time. The clock is coming into the FPGA so > you should verify that it is good using an oscilloscope. No matter > what you found out if you were to implement some sort of filter as you > described you would still need to validate that the clock *really* is > doing something odd. Once you've done that the proper solution is to > fix the glitch in the clock, not try to filter it. > > The other thing is to simply re-check your state machine logic. The > most common cause for a timing failure is setup time violations. > Every state machine input needs to be driven by logic that is clocked > by that same clock signal. Any input that is not will eventually > cause a state machine to do something unusual with nearly 100% > certainty. > > What symptoms were you seeing that led you to believe that a spurious > clock was the culprit and what is your rationale for ruling out setup > or hold time violations or crossing clock domains? > > Kevin Jennings I'm trying to prove my suspicion at this point. I have no access to board clock trace (other than a via) so doing some filtering on there is out of the question. Of course the proper solution would be to fix the glitch in the clock; and if that is the case we will re-spin the board. But at this point I need to ID the root cause. This is an extremely slow interface so I am ruling out setup time violations. The clock is under 6kHz and drives into the global clock net on the FPGA. There are 25 clock pulses per transmission. The incoming clock drives a counter and the SM. The SM transitions based on the current state and the value of the counter. And yes, the whole SM process is clocked by the same clock. This is receiving data from a 3 wire serial bus: clock , enable, and data. The FPGA is a slave in this scenario. Have I seen evidence of glitching on the board net--no. I have a fairly decent scope, too: 5GS / 500MHz bandwidth; so if something was there one would think I would see it. So again I'm just trying to rule things out at this time. Most of our boards work but we have a few that exhibit this problem; which leads me to believe it is not the logic but an environmental cause. I appreciate your time, RobArticle: 136869
In comp.arch.fpga, Rob <buzoff@leavemealone.com> wrote: > > This is an extremely slow interface so I am ruling out setup time > violations. The clock is under 6kHz and drives into the global clock > net on the FPGA. There are 25 clock pulses per transmission. The > incoming clock drives a counter and the SM. The SM transitions based on > the current state and the value of the counter. And yes, the whole SM > process is clocked by the same clock. This is receiving data from a 3 > wire serial bus: clock , enable, and data. The FPGA is a slave in this > scenario. > > Have I seen evidence of glitching on the board net--no. I have a fairly > decent scope, too: 5GS / 500MHz bandwidth; so if something was there one > would think I would see it. So again I'm just trying to rule things out > at this time. Most of our boards work but we have a few that exhibit > this problem; which leads me to believe it is not the logic but an > environmental cause. Have you looked at the rise and fall times of your signals? I know there are maximum rise and times in xilinx spartan datasheets and suspect this to be the case for other FPGAs as well. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) New Hampshire law forbids you to tap your feet, nod your head, or in any way keep time to the music in a tavern, restaurant, or cafe.Article: 136870
On 2008-12-10, Mike Treseler <mtreseler@gmail.com> wrote:
> Rob wrote:
>
>> The clock is under 6kHz and drives into the global clock
>> net on the FPGA. There are 25 clock pulses per transmission.
>
> Then this is an input.
> The synchronous clock should be constant.
>
> -- Mike Treseler
So if I understand this corectly you have one internalal FPGA clock
running in the MHz range (I guess anyway). Then you have an input
clock that you try to use to drive some internal synchronous logic.
This is a sure recipe for disaster.
First of all remember to synchronize all asynchronous inputs.
Async --> [ FF driven with internal clock ] --> To logic.
If you need to check for a clock edge on the incoming clock. Do as
follows.
module(input wire clk_i,
//At least double the speed of the slow clock.
input wire in_slow_clk, ...);
logic sync_slow_clk;
logic old_in_clk;
logic slow_rising_edge;
always_ff@(posedge clk_i) begin
sync_slow_clk <= in_slow_clk;
old_in_clk <= sync_slow_clk;
end
assign slow_rising_edge = sync_slow_clk & ~old_in_clk;
Then write all of your logic depending in the rising edge of the slow
clock like this:
always_ff@(posedge clk_i) begin
if(rst_i) begin//If needed
//Do reset stuff
else
if(slow_rising_edge) begin
//Do synchronous logic depending on slow clock
end
end
Article: 136871On Dec 9, 11:27=A0pm, Rob <buz...@leavemealone.com> wrote: > > I'm trying to prove my suspicion at this point. =A0I have no access to > board clock trace (other than a via) so doing some filtering on there is > out of the question. Of course the proper solution would be to fix the > glitch in the clock; and if that is the case we will re-spin the board. > =A0 But at this point I need to ID the root cause. I agree, and a scope is the only thing that will be the smoking gun that proves the clock has a problem that needs fixing. If the scope shows... - The transitions are all getting to valid logic levels - Rising and falling edges are monotonic - No glitches or runt pulses. - Rise and fall times are neither too fast nor too slow for the receiving part Then you would best spend your time looking elsewhere. Each of these things can be specifically triggered on without much difficulty so if you can cause your FPGA's state machine to get into the bad state and none of those conditions occurred, it likely isn't the cause. > > This is an extremely slow interface so I am ruling out setup time > violations. =A0The clock is under 6kHz and drives into the global clock > net on the FPGA. =A0 Have you verified with a scope that that the actual system is meeting whatever setup and hold time requirements are reported in the FPGA's timing report? The clock speed being slow does not imply that inputs are arriving at the proper time. > There are 25 clock pulses per transmission. =A0The > incoming clock drives a counter and the SM. =A0The SM transitions based o= n > the current state and the value of the counter. =A0And yes, the whole SM > process is clocked by the same clock. =A0This is receiving data from a 3 > wire serial bus: clock , enable, and data. =A0The FPGA is a slave in this > scenario. > My question in the first post was regarding inputs to the state machine and whether or not they are clocked from the same clock as the state machine. As you've described things, it sounds like you have at least two clocks in your design since you said in the OP... "I want to sample the clock and verify that the pulse I'm seeing is a true pulse. I'm thinking about something simple like making sure the incoming pulse is high for 3 or 4 sample clock periods" If the input clock is the only clock in the FPGA there could be no concept of sampling it to see if it was high for 3 or 4 clock periods since by definition it would only be high for roughly 1/2 of a clock cycle (assuming 50% duty cycle). So if there are two clock domains in the FPGA design, then are there *any* signals that are input signals to the state machine that come from the other clock domain? If so, they are the culprits regardless of how infrequently those signals may or may not occur. > Have I seen evidence of glitching on the board net--no. =A0I have a fairl= y > decent scope, too: 5GS / 500MHz bandwidth; so if something was there one > would think I would see it. =A0So again I'm just trying to rule things ou= t > at this time. =A0 The scope would rule it out checking for each of the conditions mentioned earlier. The other thing to try would be to modify the FPGA design (if necessary) to bring out some signal that clearly indicates when the state machine has gone into the bad state. Then look at that signal using it as a trigger and look at the clock on the scope. If there is no evidence of anything unusual on the clock prior to the trigger than you can definitively rule out the clock since the scope will be showing you precisely what the clock looked like at the time when things went bad. > Most of our boards work but we have a few that exhibit > this problem; which leads me to believe it is not the logic but an > environmental cause. > When things work 'most of the time' (i.e. not 'always') or 'some' boards work (but not 'all') the root cause is darn near always timing violations. The other root cause is power delivery. Although this is less frequent it is worth verifying that power to the parts is within the +/- 5% spec. If heating or cooling some part on the circuit boards causes *any* change (i.e. breaks a working board or fixes a broken one for some period of time) then the cause is a timing violation. Kevin JenningsArticle: 136872
I too had same problem with edk/ise 9.2i. There might be certain bugs in the initial release. After installing service packs (ise sp4, edk sp2), the problem is solved.Article: 136873
Rob wrote: > The clock is under 6kHz and drives into the global clock > net on the FPGA. There are 25 clock pulses per transmission. Then this is an input. The synchronous clock should be constant. -- Mike TreselerArticle: 136874
On Dec 10, 7:48=A0am, Per <perk-nos...@isy.liu.se> wrote: > On 2008-12-10, Mike Treseler <mtrese...@gmail.com> wrote: > > > Rob wrote: > > >> The clock is under 6kHz and drives into the global clock > >> net on the FPGA. =A0There are 25 clock pulses per transmission. > > > Then this is an input. > > The synchronous clock should be constant. > > > =A0 -- Mike Treseler > > So if I understand this corectly you have one internalal FPGA clock > running in the MHz range (I guess anyway). Then you have an input > clock that you try to use to drive some internal synchronous logic. > This is a sure recipe for disaster. > > First of all remember to synchronize all asynchronous inputs. > > Async --> [ FF driven with internal clock ] --> To logic. > > If you need to check for a clock edge on the incoming clock. Do as > follows. > > module(input wire clk_i, > =A0 =A0 =A0 //At least double the speed of the slow clock. > =A0 =A0 =A0 input wire in_slow_clk, ...); > > logic sync_slow_clk; > logic old_in_clk; > logic slow_rising_edge; > > always_ff@(posedge clk_i) begin > =A0 =A0sync_slow_clk <=3D in_slow_clk; > =A0 =A0old_in_clk <=3D sync_slow_clk; > end > > assign slow_rising_edge =3D sync_slow_clk & ~old_in_clk; > > Then write all of your logic depending in the rising edge of the slow > clock like this: > > always_ff@(posedge clk_i) begin > =A0 if(rst_i) begin//If needed > =A0 =A0 =A0//Do reset stuff > =A0 else > =A0 if(slow_rising_edge) begin > =A0 =A0 //Do synchronous logic depending on slow clock > =A0 end > end There are no asynchronous inputs. All the inputs are sync'd to the incoming slow 6kHz clock. The other fast internal FPGA MHz clock is for something completely unrelated and has nothing to do with the SM. Rob
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