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 Jan 8, 6:20=A0am, Eli Bendersky <eli...@gmail.com> wrote: > Hello, > > Suppose that I'm sampling an asynchronous signal with a FF, without > using any synchronizers before it. This FF will become metastable from > time to time with a MTBF depending on the device's parameters, the > clock rate and the input signal change rate. > Your item #2 describes the most common problem, exacerbated by excessive routing delay differences. Peter Alfke > Can you please suggest *real life* examples of how this can make me > fail in a real design, that is, where the time of recovery for the > metastable event is indeed 0. Here are two off the top of my head: > > 1) The output of this FF can be used directly as the output of the > device, causing an intermediate value on the output for some time, > which can harm other devices. > > 2) If such an input is sampled by two different FFs for different > purposes, they may end up with different results. > > Thanks in advance, > EliArticle: 127801
On Jan 8, 10:58 am, jeroen.cl...@gemidis.be wrote: > setup: > On one of our designs we are using a Xilinx partan3 FPGA (XC3S500E -4 > FT(G)256 stepping1) and an spi flash (M25P40-VMN6) to store FPGA code, > callibration data, board settings,... > > Problem description: > Random SPI commands on the SPI bus from the FPGA to the flash are > logged during a power down of the board. Sometimes a complete SPI > write sequense is logged which makes the flash content corrupt. > > root cause: > Power down of the FPGA is not correct accoarding to the spec. The fall > time of the power supply is to long. this results in a bad behaviour > of the micro Blaze(uB). During power down the pointer of the uB is > jumping to a random place in the uB code. From this point the uB > executes several actions depending on the fall time of the power > supply. It happens that the pointer jumps to the "write_spi_flash" > function in the code. > > solution: > The best solution is to make the power off sequense of the FPGA > according to the spec. It is possible to place a power monitor on the > board but this results in a redesign of the board and we do not > prefere to do so. > > question: > Is there somebody who knows another solution that does not require a > redesign of the board? Does the microblaze know that it will be shut down ? If so, you can erase the whole program memory from the BRAM before shutting down ... Or add some hardware to disconnect the IOB of the SPI once you shutdown ... But it all pretty much implies you know when you shutdown ... SylvainArticle: 127802
On Jan 8, 4:48 pm, Ben Jackson <b...@ben.com> wrote: > On 2008-01-08, Zorjak <Zor...@gmail.com> wrote: > > > > > Can flex 8000 series be programed in the same way as cyclone families. > > There are differences. I think FLEX actually has MORE ways to configure, > eg parallel. > > > Which programing file is used when fpga is programed .sof or .pof. Is > > the programing equipment compatible. > > A sof is an "sram object file" and is the actual FPGA bitstream. A > pof (programming object file??) is a container for writing flash devices. > You can put more than one sof in a pof (as well as other data). > You use the sof if you do direct JTAG programming. > > The 'programming equipment' is typically an Altera byteblaster cable. > The byteblaster MV cannot program flash devices (iirc) while the > byteblaster II can. > > -- > Ben Jackson AD7GD > <b...@ben.com>http://www.ben.com/ Thank You for your answer, Bob ZoranArticle: 127803
jeroen, What I would do is add code to the spi_write subroutine that checks who called it (a list of allowed calling locations is checked before execution), and/or add a check in the spi_write subroutine that a specific memory location or register has been written to in order to allow the operation. Then before every legitimate call to the spi_write, the special added register has the "go" command written to it, and that command is immediately cleared when recognized by the spi_write subroutine (so it can't happen again without intending it to). The command should be something that is different than any powering down condition, something like 0xAAh, or 0x55h for example. AustinArticle: 127804
I am unable to infer a True Dual Port RAM in ispLEVER using VHDL. I'm targetting the Lattice ECP2M using Synplify. Even the provided example located in isptools7_0\examples\fpga\latticexp2\memory\inferencing\true_dual_port\vhdl\true_dual_port.vhd does not synthesize successfully. Has anyone else had any better luck at this? Thanks, ColinArticle: 127805
On Jan 8, 6:38 pm, Peter Alfke <pe...@xilinx.com> wrote: > On Jan 8, 6:20 am, Eli Bendersky <eli...@gmail.com> wrote:> Hello, > > > Suppose that I'm sampling an asynchronous signal with a FF, without > > using any synchronizers before it. This FF will become metastable from > > time to time with a MTBF depending on the device's parameters, the > > clock rate and the input signal change rate. > > Your item #2 describes the most common problem, exacerbated by > excessive routing delay differences. > Peter Alfke > Hi Peter, thanks for answering. Could you provide a piece of VHDL/Verilog code that is realistic and has this problem ?Article: 127806
On Jan 8, 12:53=A0pm, j...@capsec.org wrote: > Strange, I remember DCM_SP is the DCM variant one should use in > Spartan3E... Can't remember for sure... DCM_SP should be correct, it is the Spartan3E DCM. AndrewArticle: 127807
Hello, I have Spartan 3E1600E Microblaze Development kit with FPGA marked as: ----------------------------- Xilinx SPARTAN XC3S1600E FGG320DGQO617 A1408025A1 4C ----------------------------- KOREA How I could know its package type? It should be either FG320, or FG400, or FG484. Looking at chip's appearance I thought that it is FG484 (as I know how this looks) but it's marked as FGG320DGQO617 so I am not sure which package type of my FPGA is?Article: 127808
"Vagant" <vladimir.v.korostelev@rambler.ru> wrote in message news:81f5ec31-8be7-49e8-b6df-cfe671cfa232@d70g2000hsb.googlegroups.com... > Hello, > I have Spartan 3E1600E Microblaze Development kit with FPGA marked as: > > ----------------------------- > Xilinx > SPARTAN > XC3S1600E > FGG320DGQO617 > A1408025A1 > 4C > ----------------------------- > KOREA > > How I could know its package type? It should be either FG320, or > FG400, or FG484. > Looking at chip's appearance I thought that it is FG484 (as I know how > this looks) but it's marked as FGG320DGQO617 so I am not sure which > package type of my FPGA is? Hi Vladimir, The clue is FGG320. Or you could could your balls. ;-) HTH., SymsArticle: 127809
"Eli Bendersky" <eliben@gmail.com> wrote in message
news:fa77eae8-4d70-412e-9a85-738b04c50647@1g2000hsl.googlegroups.com...
>
> Hi Peter, thanks for answering.
> Could you provide a piece of VHDL/Verilog code that is realistic and
> has this problem ?
>
Hi Eli,
process(clock)
begin
if rising_edge(clock) then
if bad_input = '1' then
count <= (count + 2) mod 8;
else
count <= (count + 1) mod 8;
end if;
end if;
end process;
It's possible for count to increment by 3 if the bad_input gets to bit 1 of
count before it gets to bit 0.
HTH., Syms.
Article: 127810On Jan 8, 8:20=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > "Vagant" <vladimir.v.koroste...@rambler.ru> wrote in message > > news:81f5ec31-8be7-49e8-b6df-cfe671cfa232@d70g2000hsb.googlegroups.com... > > > > > > > Hello, > > I have Spartan 3E1600E Microblaze Development kit with FPGA marked as: > > > ----------------------------- > > Xilinx > > SPARTAN > > XC3S1600E > > FGG320DGQO617 > > A1408025A1 > > 4C > > ----------------------------- > > KOREA > > > How I could know its package type? It should be either FG320, or > > FG400, or FG484. > > Looking at chip's appearance I thought that it is FG484 (as I know how > > this looks) but it's marked as FGG320DGQO617 so I am not sure which > > package type of my FPGA is? > > Hi Vladimir, > The clue is FGG320. Or you could could your balls. ;-) > HTH., Syms- Hide quoted text - > > - Show quoted text - Okay ;) I just wonder whether FG484 and FG320 chip packages are similar in appearance?Article: 127811
>...Here are two off the top of my head: > >1... >2)... Aren't those two reasons enough for avoiding it? Or are we just doing your homework? MikeArticle: 127812
>...before every legitimate call to the spi_write, the special added >register..."go" command...0xAAh, or 0x55h for example. Such "write unlock sequences" are intended to prevent a write which could otherwise be caused by a single spurious signal (e.g. as power is lost). They don't help against spurious code execution (whether at power-down or otherwise), because that's as likely to begin before the "unlock" as after. MikeArticle: 127813
>I am unable to infer a True Dual Port RAM in ispLEVER using VHDL. I'm > targetting the Lattice ECP2M using Synplify. Even the provided example > located in > isptools7_0\examples\fpga\latticexp2\memory\inferencing\true_dual_port\vhdl\true_dual_port.vhd > does not synthesize successfully. Has anyone else had any better luck at > this? It works fine with Precision. I too had the same problem with Synplify ver 8.1 IIRC. It appears that template is all wrong for Synplify. Try another one from Sunplify user guide... Happy inferencing :) > > Thanks, > Colin Maki.Article: 127814
Mike, The probability that you branch to the spi-write subroutine AFTER the check is possible, I agree. It is also possible the code branches to a valid section that is going to call the spi_write subroutine. Hence the reason why I added the check of who calls the spi_write. Of course, you can jump in right after that check, too. I think the point is to minimize the probabilities to the point where it meets the requirements of their customers. If there is one, and only one valid address that skips all the checks, then the probabilities are pretty small, and of no concern. Another suggestion was to slow things down. If the spi_write is called, it waits the power down time before continuing, that helps, too (if it is a real power down, power is down before you do anything bad). You may also call the routine just after the wait, but again, it is the statistics, AustinArticle: 127815
On Jan 8, 6:20=A0am, Eli Bendersky <eli...@gmail.com> wrote: > Hello, > > Suppose that I'm sampling an asynchronous signal with a FF, without > using any synchronizers before it. This FF will become metastable from > time to time with a MTBF depending on the device's parameters, the > clock rate and the input signal change rate. > Eli, Look at XAPP094 (you can easily google it) It shows the circuit I have used to quantify metastable delay. The delay is short, so you have to be quick to catch it... Peter Alfke > Can you please suggest *real life* examples of how this can make me > fail in a real design, that is, where the time of recovery for the > metastable event is indeed 0. Here are two off the top of my head: > > 1) The output of this FF can be used directly as the output of the > device, causing an intermediate value on the output for some time, > which can harm other devices. > > 2) If such an input is sampled by two different FFs for different > purposes, they may end up with different results. > > Thanks in advance, > EliArticle: 127816
Hello All, I have got a warning (below) during implementation of my design which uses 50 MHz clock on Spartan 3E 1600E Microblaze Development Kit. What could be a reason for this warning and how it could be fixed? WARNING:iMPACT:2257-Startup clock has been changed to 'JtagClk' in the bitstream stored in memory, but the original bitstream file remains unchanged.Article: 127817
On 2008-01-08, Rgr <rgrworking@hotmail.com> wrote: > Hi all. > I am doing a small Processor implementation (with the performance somewhat > like an 8051 CPU), and I am designing for "as low power as possible". > I want to use reconfigurable logic as I am interested in the the flexibility > and the possibility of adding additional logic to my design. I'm no expert in low-power CPLD design, but my first idea is that if you chose a CPLD without internal memories you will burn quite a lot of power while communicating with your external program/data memories. (I could also add the Lattice has a few CPLDs (more like CPLD/FPGA hybrid with built in RAM which you also might to look into.) The question is of course if you are doing this for fun or for a product. If it is for fun, do whatever you wish and learn from it :) (And if you learn something interesting while doing this, why not report it to this newsgroup.) If it is for a product I am very doubtful about using a processor in a CPLD, especially if low power is a requirement... /AndreasArticle: 127818
On Jan 8, 2:19 pm, Vagant <vladimir.v.koroste...@rambler.ru> wrote: > Hello All, > > I have got a warning (below) during implementation of my design which > uses 50 MHz clock on Spartan 3E 1600E Microblaze Development Kit. What > could be a reason for this warning and how it could be fixed? > > WARNING:iMPACT:2257-Startup clock has been changed to 'JtagClk' in the > bitstream stored in memory, but the original bitstream file remains > unchanged. You do not need to fix anything unless you just want to make the warning go away. This just means that bitgen was told to generate the bitfile with the startup clock set to CCLK. Since you are downloading with a JTAG cable, Impact automatically modified the bitfile before downloading it for you. In EDK you can edit the project_dir/etc/bitgen.ut file in your project to change the startup clock option. If you plan on putting your bitfile into what ever config memory you have on the card, I would just leave the startup clock set to CCLK like it is now. Impact will work fine with it that way, but changing it to use the JtagClk would cause you problems if you forget to change it back before creating a bitfile for the config memory. Regards, John McCaskill www.FasterTechnology.comArticle: 127819
On Jan 8, 3:19 pm, Vagant <vladimir.v.koroste...@rambler.ru> wrote: > Hello All, > > I have got a warning (below) during implementation of my design which > uses 50 MHz clock on Spartan 3E 1600E Microblaze Development Kit. What > could be a reason for this warning and how it could be fixed? > > WARNING:iMPACT:2257-Startup clock has been changed to 'JtagClk' in the > bitstream stored in memory, but the original bitstream file remains > unchanged. This is talking about the configuration startup clock, not the 50 MHz system clock of your running design. If your bitstream settings are default, your CCLK will normally be used to start up the FPGA after configuration. When using iMPACT in JTAG mode, this clock is not available, so iMPACT changes it for you to use the JTAG TCK signal instead. This is the normal behavior, and you don't need to worry about it. Additional information on configuration is available in the Spartan 3 Generation Configuration User Guide, ug332.pdf, available on the Xilinx website.Article: 127820
Symon wrote: (snip) > process(clock) > begin > if rising_edge(clock) then > if bad_input = '1' then > count <= (count + 2) mod 8; > else > count <= (count + 1) mod 8; > end if; > end if; > end process; > It's possible for count to increment by 3 if the bad_input > gets to bit 1 of count before it gets to bit 0. I would have called this an ordinary setup/hold violation. If the problem is due to timing of bad_input, propagated through the MUX that I presume it generates, then it should be setup/hold violation. Metastability should occur due to clock rate issues, through the appropriate propagation delay, but independent of bad_input, and only if bad_input does satisfy setup/hold. I would say that the usual cause of option 2 in the previous post is also setup/hold violation. Note that this system can fail even with perfect FFs due to different propagation delays. -- glenArticle: 127821
On Jan 8, 3:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Symon wrote: > > (snip) > > > process(clock) > > begin > > if rising_edge(clock) then > > if bad_input = '1' then > > count <= (count + 2) mod 8; > > else > > count <= (count + 1) mod 8; > > end if; > > end if; > > end process; > > It's possible for count to increment by 3 if the bad_input > > gets to bit 1 of count before it gets to bit 0. > > I would have called this an ordinary setup/hold violation. > > If the problem is due to timing of bad_input, propagated > through the MUX that I presume it generates, then it should > be setup/hold violation. > > Metastability should occur due to clock rate issues, through > the appropriate propagation delay, but independent of bad_input, > and only if bad_input does satisfy setup/hold. > > I would say that the usual cause of option 2 in the previous > post is also setup/hold violation. > > Note that this system can fail even with perfect FFs due to > different propagation delays. > > -- glen I agree, #2 is independent of metastability; it is a parallel synchronizer, which is a bad thing. If the propagation skew is more than setup+hold to all of the destination registers, it could meet setup and hold on all of them (avoiding metastability), while still failing functionally (incrementing by 3). AndyArticle: 127822
Symon wrote: (snip, I wrote) >>Symon wrote: >>>Do you not think that the trace inductance and magnetic field are >>>important? You don't mention them at all in your post. Just thinking >>>about the capacitance is not the whole story... >>Inductance that is part of an impedance matched transmission >>line doesn't count. > And why is that? For an impedance matched line, the inductance and capacitance balance out. This might be easier to see for a line that is not impedance matched. It is common for telephone lines to be UTP cable of around 100 ohm impedance driven by a 600 ohm source. The frequency has to be low enough, but that isn't a problem for telephone lines. What does happen, though, is that the excess capacitance causes a high frequency drop off. A 600 ohm line would have more inductance (per unit length) or less capacitance (per unit length). This fix for this is to add series inductors periodically along the length, maybe every 5000 feet. This improves the frequency response in the voice band, with a sharp drop after that. http://en.wikipedia.org/wiki/Load_coil >> The situation at the end, where the trace >>crosses the gap is a little complicated. As the current spreads >>out in the split plane, it isn't quite a transmission line anymore. >>The half plane inductance should be pretty low, but it won't >>say it doesn't count. > What about the increased loop area because the current > goes around the slot? At low frequencies it goes around. As the frequency increases, the capacitance of the system is enough to support the current. At really high frequencies (wavelength much shorter than the dielectric thickness) the problem goes away. > Does this increase the generation of the magnetic field? Are you only > considering the inductance of the plane, or the inductance of the trace > also? The assumption is that the trace is properly impedance matched to its load and source. >>At some point I made the assumption that there was something on >>the other side of the split plane to make a good capacitor. >>(Another split plane would do. It would work on either side.) > You really lost me there. Sorry. Well, as an example, both split power and ground planes, with the signal line either between them or on one side. >>Consider a circular parallel plate capacitor fed at the center. >>Then consider it as concentric ring capacitors and the radial >>inductance of those rings. The inductance per (radial) length >>decreases with increasing radius, the capacitance per radial >>distance increases with increasing radius. I believe that makes >>capacitance win out over inductance for reasonable frequencies. > How does the current get from the centre to these "concentric ring > capacitors"? I think it travels out radially, and this current > generates a magnetic field. And the voltage generates an electric field. The result is a transmission line in the radial direction. The impedance, sqrt(L/C), decreases fast with radius, the velocity, depending on LC, stays constant with radius. The decreasing impedance makes it look capacitive to the load for radius greater than the trace width. (You can also see that through the increasing capacitance and decreasing inductance with increasing radius.) The decreasing impedance with distance allows it to support the needed current, assuming the wires crossing the split aren't too close together. -- glenArticle: 127823
On Jan 8, 3:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Symon wrote:
>
> (snip)
>
> > process(clock)
> > begin
> > if rising_edge(clock) then
> > if bad_input = '1' then
> > count <= (count + 2) mod 8;
> > else
> > count <= (count + 1) mod 8;
> > end if;
> > end if;
> > end process;
> > It's possible for count to increment by 3 if the bad_input
> > gets to bit 1 of count before it gets to bit 0.
>
> I would have called this an ordinary setup/hold violation.
>
> If the problem is due to timing of bad_input, propagated
> through the MUX that I presume it generates, then it should
> be setup/hold violation.
>
> Metastability should occur due to clock rate issues, through
> the appropriate propagation delay, but independent of bad_input,
> and only if bad_input does satisfy setup/hold.
>
> I would say that the usual cause of option 2 in the previous
> post is also setup/hold violation.
>
> Note that this system can fail even with perfect FFs due to
> different propagation delays.
>
> -- glen
Example #1
process (event, out2) is
begin
if out2= '1' then
out1 <= '0';
elsif rising_edge(event) then
out1 <= '1';
end if;
end process;
process (clk2) is
begin
if rising_edge(clk2) then
out2 <= out1;
end if;
end process;
A long, long time ago, I once had this problem on a board (74f74 dual
flops), where another circuit running on clk2 was also looking at
out2. The second flop (out2) would go metastable true just long enough
to reset out1, and then settle false, so the other circuit would not
see it on the next clk2. Since out1 had been reset, it was not there
the next clk2, and was lost.
Note these are very poor design practices for FPGAs (use of async
reset for anything but initialization), but were very common on board
level designs (when done properly).
Andy
Article: 127824
Eli Bendersky wrote:
> 1) The output of this FF can be used directly as the output of the
> device, causing an intermediate value on the output for some time,
> which can harm other devices.
This FF might be used as an input synchronizer
intended to eliminate logic races.
Setup and hold violations are to be expected
for a synchronizer and in almost all cases
synchronization succeeds anyway.
But maybe once a year, the bowling ball
stops on the speed bump and synchronization fails
and the synchronizer causes a logic race.
The race may or may not cause a bad state transition.
A bad transition may or may not cause
an observable error.
I might be able to improve my odds to say,
one synchronization failure in 100 years
by using a two stage synchronizer, but
I can't eliminate the possibility.
> 2) If such an input is sampled by two different FFs for different
> purposes, they may end up with different results.
This is the case of the *missing* synchronizer.
This is often confused with metastability,
but it is really a design error.
I don't have to wait nearly as long to
observe an error in this case.
-- 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