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
Anyone, I am looking for information concerning the neccissary files required from a completed project to reuse in a new project. I write a top level driver file in VHDL and often insert core generated processes. I run into trouble when inserting the driver file into a new project when core gen files were used. Specifically it is looking for a wrapped_porcess (.xco ?). Question does ISE create a folder of neccissary files of current project to be used in subsequent projects. Sincerley Cy DrollingerArticle: 90151
Is that with useA and useB as hard elements? If you define useA and useB combinatorially without some form of a "keepbuf" it would be easy to confuse the compiler. If you're not sure about the treatment of useA and useB, try defining them as a sub-module to keep the instantiation to the 4 inputs per LUT stage. "Sylvain Munaut" <com.246tNt@tnt> wrote in message news:43440eee$0$14841$ba620e4c@news.skynet.be... > John_H wrote: > > I use similar structures in Synplify all the time. I don't see why XST > > would do a poor implementation of the same thing as long as it knows that > > useA and useB are wires and not to integrate the combinatorial equations for > > useA and useB into the adder. I modified the diagram to illustrate how the > > representation fits your need. > > > > Yeah, I confused the two choices of CYMUX ... My bad. The two > representation works just fine. > > But XST doesn't understand yours either ... it also uses two level with > useA and useB ... > > > Sylvain <snip>Article: 90152
yup, I created a "test" entity just for that (to avoid long synthesis of the whole stuff each time I test a thing). John_H wrote: > Is that with useA and useB as hard elements? If you define useA and useB > combinatorially without some form of a "keepbuf" it would be easy to confuse > the compiler. If you're not sure about the treatment of useA and useB, try > defining them as a sub-module to keep the instantiation to the 4 inputs per > LUT stage. > > "Sylvain Munaut" <com.246tNt@tnt> wrote in message > news:43440eee$0$14841$ba620e4c@news.skynet.be... > >>John_H wrote: >> >>>I use similar structures in Synplify all the time. I don't see why XST >>>would do a poor implementation of the same thing as long as it knows > > that > >>>useA and useB are wires and not to integrate the combinatorial equations > > for > >>>useA and useB into the adder. I modified the diagram to illustrate how > > the > >>>representation fits your need. >>> >> >>Yeah, I confused the two choices of CYMUX ... My bad. The two >>representation works just fine. >> >>But XST doesn't understand yours either ... it also uses two level with >>useA and useB ... >> >> >>Sylvain > > > <snip> > >Article: 90153
CMOS wrote:
> what im asking is, we have "clock", which is an input to the entity and
> a signal called "clk" declared in the entity. The input "clock" is
> mapped to the signal "clk". In all other places only "clk" is used, but
> "clock" is never used. What is the difference of doing this from just
> using "clock" everywhere and eliminating "clk" altogether?
You can, and should, use the port signal "clock" instead of using
assigned signal "clk."
There IS a restriction that applies to using _output_ ports within an
entity's architecture. You can only assign to that signal; you cannot
use it on the right-hand side of an assignment statement. So it's
common to see:
entity foo (a : in std_logic; b : out std_logic); end entity foo;
architecture bar of foo is
signal bletch : std_logic;
begin
bletch <= b; -- not allowed!
end architecture bar;
Is your example from a bit of code someone else wrote and you need to
understand?
-a
Article: 90154
Peter Alfke wrote:
> The rule still is: If you have reason to worry about metastability,
> give the flip-flop in question maximum slack to settle, and have it
> drive only one near-by synchronizing flip-flop. Without that
> precaution, you might get into trouble...
Peter, rookie question: given the following synchronizer:
module test(input clk, input in_sig, output reg out_sig);
reg [1:0] ss;
always @(posedge clk)
begin
out_sig <= ss[1];
ss <= { ss[0], in_sig };
end
endmodule
How, specifically, do I tell XST to locate ss[1] as close as possible
to ss[0]?
Regards,
Paul.
Article: 90155
Paul,
Unless Peter has hidde talents I am unaware of, let me try to answer this.
Apply minimum time constraint to the routing of the signals in question.
This may be difficult to do, as if you overconstrain, the tools give up,
without necessarily finding the best they can do (why work hard on
something that can't be done?).
An alternative is to look at the placed and routed design in FPGA Editor
so you can find the actual delays on the nets in question. If the
delays are not acceptable, you can reroute by hand.
This is obviously tiresome, and difficult, which is the reason why you
should not be doing this at all: one should register the signal in
question ONCE, and then route it to where it is needed or used.
It is poor design to sample any signal more than one time, and expect to
get the same result if timing is not guaranteed (ie synchronous with the
proper setup and hold times being always observed).
Austin
Paul Marciano wrote:
> Peter Alfke wrote:
>
>>The rule still is: If you have reason to worry about metastability,
>>give the flip-flop in question maximum slack to settle, and have it
>>drive only one near-by synchronizing flip-flop. Without that
>>precaution, you might get into trouble...
>
>
> Peter, rookie question: given the following synchronizer:
>
> module test(input clk, input in_sig, output reg out_sig);
> reg [1:0] ss;
>
> always @(posedge clk)
> begin
> out_sig <= ss[1];
> ss <= { ss[0], in_sig };
> end
> endmodule
>
>
> How, specifically, do I tell XST to locate ss[1] as close as possible
> to ss[0]?
>
>
> Regards,
> Paul.
>
Article: 90156
> Melissawrote:
In fact, I had already put this configuration statments in the end of
my testbench, but I didn't see the software working. My system just
writes the value '1' in a register(slv_reg0) and '2' in
another(slv_reg1), but when I simulate the system in ModelSim the
registers continue with the value '0'. Shouldn't it change the value
of my registers?
> Thank you!
>
> Sylvain Munautwrote:
Melissa Vetromille wrote:
> Hello!
>
> I have a system implemented in hardware and I prototyped it in
> VIrtex-II Pro platform with a testbench. I analyzed the signals
using
> chipscope and it worked the same as in simulation. After this, I
> created a project in EDK and substituted the testbench by a
> Microblaze processor. The project stopped working. Now, I need to
> debug the harwdare in order to find the problem, ut I don't know
how
> to do this. I'm trying to use ModelSim.
> In fact, I generated the simulation files and created the testbench
> file to stimulate my system. However, this testbench just generates
> the clock and reset, so I need instanciate my software in order to
> generate the other stimulus. Is it possible? What do I have to do
in
> order to incorporate my software in simulation? Does anyone can
help
> me?
>
> Thank you!
>
> Melissa
>
>
If your tb entity name is Test_sim and if your EDK system instance is
UUT, add this to your testbech :
configuration tb_conf of Test_sim is
for testbench_arch
for UUT: system
use configuration work.system_conf;
end for;
end for;
end tb_conf;
Also, simulate the tb_conf configuration and not just your test bench
entity. (when selecting what to simulate).
EDK will also create a system.do or a .do to load everything needed
IIRC.
Sylvain[/quote:95a6018ae6]
Article: 90157> Melissawrote: I had already tryied to debug using chipscope, but it showed an error. The place and route report showed that I have 1 BSCAN and with chipscope I have to use another. So, I'm trying to use 2 BSCANs and it overmaps the FPGA. What do I have to do in order to use chipscope? I inserted a chipscope_icon and a chipscope_opb_iba. Do I have to insert something else? > Thank you! > > Zarawrote: On Tue, 04 Oct 2005 19:16:46 -0500, > mvetromille@gmail-dot-com.no-spam.invalid (Melissa Vetromille) wrote: > > Hello! > > I have a system implemented in hardware and I prototyped it in > VIrtex-II Pro platform with a testbench. I analyzed the signals using > chipscope and it worked the same as in simulation. After this, I > created a project in EDK and substituted the testbench by a > Microblaze processor. The project stopped working. Now, I need to > debug the harwdare in order to find the problem, ut I don't know how > to do this. I'm trying to use ModelSim. > In fact, I generated the simulation files and created the testbench > file to stimulate my system. However, this testbench just generates > the clock and reset, so I need instanciate my software in order to > generate the other stimulus. Is it possible? What do I have to do in > order to incorporate my software in simulation? Does anyone can help > me? > > Thank you! > > Melissa > For me, the best way to debug hardware with a microblaze inside is to instantiate a ChipSocpe icon and ila inside the design, connected to the secondary bscan port of an opb_mdm connected to the microblaze. This way, you may debug hardware or software (not simultaneously) easily.[/quote:388bc6029c]Article: 90158
On 5 Oct 2005 15:33:44 -0700, "Paul Marciano" <pm940@yahoo.com> wrote: > >Peter Alfke wrote: >> The rule still is: If you have reason to worry about metastability, >> give the flip-flop in question maximum slack to settle, and have it >> drive only one near-by synchronizing flip-flop. Without that >> precaution, you might get into trouble... > >Peter, rookie question: given the following synchronizer: I'm not Peter, but you could put the following two lines in your UCF: INST "ss_1" LOC = "CLB_R1C1.S0" ; INST "ss_0" LOC = "CLB_R1C1.S0" ; If you don't like the upper left corner, change both lines to different rows and columns to move it. Or if you want the tools to automatically place both FFs, put the following two lines in your UCF: INST "ss_1" RLOC = "R0C0.S0" ; INST "ss_0" RLOC = "R0C0.S0" ; It would be more complex if one FF was in an IOB, or was an output from BlockRAM. It could be done with attributes in the source. This can get well beyond a rookie question! Also, should make sure the routing agrees: Add something like the following to the UCF: INST "ss_1" TNM = "SYNC_FF"; INST "ss_0" TNM = "SYNC_FF"; TIMESPEC "TS_SYNCS" = FROM "SYNC_FF" TO "SYNC_FF" 2.5 ns; The time value needs to be adjusted based on the family, speed grade, and other variables. -- Phil Hays to reply solve: phil_hays at not(coldmail) dot com If not cold then hotArticle: 90159
Well, Philip and I are good friends since 25 years back, that's why I let him call me "dead wrong". And we have a long-standing controversy about the dangers of metastability. My error was making the tacit assumption that a 24 MHz design would always have 3 ns slack. I should have suggested to force the router to assume 33 Mhz, which would then absolutely guarantee an extra 8 ns of slack. The design in question was descibed as dead slow.... Then the question of device generation: 8 years ago, in XC4008-8 devices, I measured 4 decimal orders of magnitude increase in MTBF fo every extra ns. (But that device was very slow even then) XC4005-3 was faster, and increased MTBF by 8 orders of magnitude per ns. And Virtex2Pro increased by 9 orders of magnitude, and has a much shorter basic delay. It's all documented in XAPP094. So you really have to go to the museum to get parts with slow recovery from metastability. Like 74S74 and 74H74 dual flip-flops, the arch-villains of bad metastable behavior in the 'sixties and 'seventies. But who cares about them today? In many cases, designers just make the fundamentally unforgivable mistake of synchronizing an asynchronous input in two parallel paths, always expecting the identical result. Fat chance. Philip wants to make sure that we all stay alert against the evil force of metastabilty, while I want to make people aware that the problem often is elsewhere. We are not that far apart. Peter Alfke, from home.Article: 90160
The Xilinx website isn't too clear with respect to the evaluation EDK included with the Spartan-3 starter kit. Does anyone know if it is time limited or feature limited? Can I run the reference microblaze designs with it? Also, does anyone know if the starter kit will ship with ISE/EDK 8.1i when it itself ships? Thanks! cheers, aaronArticle: 90161
aholt...@gmail.com wrote: > The Xilinx website isn't too clear with respect to the evaluation EDK > included with the Spartan-3 starter kit. Does anyone know if it is time > limited or feature limited? Can I run the reference microblaze designs > with it? Also, does anyone know if the starter kit will ship with > ISE/EDK 8.1i when it itself ships? Thanks! > > cheers, > aaron Aaron, IIRC, the Spartan 3 Eval kit shipped with a 60 day eval EDK 6_3 back in Feb 2005. It also came with a 60 day ISE6_3 eval. I have no information what they ship now. -NewmanArticle: 90162
Oops,
Looks like I read the 'english', and not the code.
Looks like it is registered once, and then sent to another FF. Both
FF's are clocked on the rising edge, so it is not a metastability
"filter" (which would clock the second FF on the falling edge) to reduce
the probability of a metastable event (they can not be prevented, but
the statistics can be improved to where you just don't care).
That is a standard looking shift register.
No issue with that.
The FPGA fabric is always slower than a global clock (except in some
rare cases where things are really poorly placed due to other issues
with poor or confusing or conflicting constraints), so there is no
problem (like there could be in an ASIC) that the data might get to some
FF's before the clock would (and an event is missed altogether).
The tools should make a reasonably good placement to prevent problems.
I have seen where folks used location constraints to be sure that the
clock arrived at the MSB or last stage first, and then went against the
flow of data towards the LSB or first stage to ensure that the clock
would always get to the FF BEFORE the data coming to the FF could
possibly change in ASIC standard cell flows. Not really needed in an
FPGA: the fabric and clocks are supposed to be "correct by
construction" so the engineer doesn't have to worry.
This whole thing also has nothing to do with metastability.
Austin
Austin Lesea wrote:
> Paul,
>
> Unless Peter has hidde talents I am unaware of, let me try to answer this.
>
> Apply minimum time constraint to the routing of the signals in question.
>
> This may be difficult to do, as if you overconstrain, the tools give up,
> without necessarily finding the best they can do (why work hard on
> something that can't be done?).
>
> An alternative is to look at the placed and routed design in FPGA Editor
> so you can find the actual delays on the nets in question. If the
> delays are not acceptable, you can reroute by hand.
>
> This is obviously tiresome, and difficult, which is the reason why you
> should not be doing this at all: one should register the signal in
> question ONCE, and then route it to where it is needed or used.
>
> It is poor design to sample any signal more than one time, and expect to
> get the same result if timing is not guaranteed (ie synchronous with the
> proper setup and hold times being always observed).
>
> Austin
>
>
>
> Paul Marciano wrote:
>
>> Peter Alfke wrote:
>>
>>> The rule still is: If you have reason to worry about metastability,
>>> give the flip-flop in question maximum slack to settle, and have it
>>> drive only one near-by synchronizing flip-flop. Without that
>>> precaution, you might get into trouble...
>>
>>
>>
>> Peter, rookie question: given the following synchronizer:
>>
>> module test(input clk, input in_sig, output reg out_sig);
>> reg [1:0] ss;
>>
>> always @(posedge clk)
>> begin
>> out_sig <= ss[1];
>> ss <= { ss[0], in_sig };
>> end
>> endmodule
>>
>>
>> How, specifically, do I tell XST to locate ss[1] as close as possible
>> to ss[0]?
>>
>>
>> Regards,
>> Paul.
>>
Article: 90163Philip, I always enjoy reading patents that claim to eliminate metastability. Seems that the patent office has never figured this one out: they did make it a law that perpetual motion machines are not patentable, but there is no such restriction for metastability "eliminators" (all of which don't work!). Many of these clever circuits perform worse than the standard solutions found in any good textbook on the subject, as you point out. Austin Philip Freidin wrote: > Hi Bill, > > On Tue, 4 Oct 2005 12:16:04 +0200, "Bill" <billbill@telia.se> wrote: > >>Is the following a good way to avoid meta stability problems? The signal 'd' >>is synchronous to a 1.8 MHz clock? > > > And from your code I assume that the synchronizing clock is > 24 MHz. > > > The answer to yor question is that your solution is NOT a good > way to "avoid" metastability. > > First, you can't avoid it, you can only make its effect lower > probability. The way to make it lower probability is to have > additional settling time within the synchronizer. > > Second, while your circuit is clever, it boils down to > a two stage synchronizer, with logic (your median circuit) > between the first and second stage. This logic subtracts > from the resolving time available between the first stage > and the second stage of your synchronizer. As is often the > case with proposed circuits to help mitigate metastability > in clock domain crossing circuits, what you have done is > made the analysis of the behavior harder, but the result is > not as good as just two flipflops. > > Peter's response to you is dead wrong in this part: > >>There are more important things to worry about, forget metastability... > > > in this part: > >>If you run a 1.8 MHz clock (even with a similar asynchronous data >>rate), your chance of having a 3 ns extra metastable delay is once per >>billion years (at 24 MHz it would be only 5 million years). > > > the assumption of 3 ns slack is unsupported, and if you are using > Xilinx's crappy FPGA router (you don't say which product you are > targetting) then there may be no slack regardless of what the cycle > time is, although as clock rates drop the likelyhood of there > being no slack diminishes. This is because the router stops trying > to improve the route as soon as the timing specification is met. > At this point there is no slack. > > This issue can be helped by adding specific timing constraints to > the synchronizer circuit that force additional resolving time by > specifying path requirements that are more demanding than the > clock cycle time implies. > > in this part: > >>For every additional ns of acceptable settling time, the >>mean-time-between-failure increases at least a million times. (see >>XAPP094 on the Xilinx website) > > > this rule of thumb depends on what product you are using. The 1E6 > is for the latest devices. You may be using something else. > Older technology may have numbers as low as 1E2. > > In summary, you will be better served with a simple two stage > synchronizer, with as tight a timing constraint as you can use > to maximize the slack time between the first and second flip flops. > > You can read FAR more on the subject at this URL: > > http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm > > > >>... your VHDL ... > > > > > Philip Freidin > > > > =================== > Philip Freidin > philip.freidin@fpga-faq.org > Host for WWW.FPGA-FAQ.ORGArticle: 90164
I apologize that my question was not clean. Each element of matrix is just single precision real number. Both of floating and fixed point implementations are allowed. Because it's my small project, so I cannot pay for the IP. So now I try to use some related libraries of coregen. Thanks a lot for your advice, Robin. And any further guide, that'll be great help for me. Thanks again.Article: 90165
On Wed, 05 Oct 2005 19:16:02 -0500, mvetromille@gmail-dot-com.no-spam.invalid (Melissa Vetromille) wrote: >> Melissawrote: >I had already tryied to debug using chipscope, but it showed an >error. The place and route report showed that I have 1 BSCAN and >with chipscope I have to use another. So, I'm trying to use 2 BSCANs >and it overmaps the FPGA. What do I have to do in order to use >chipscope? I inserted a chipscope_icon and a chipscope_opb_iba. Do I >have to insert something else? >> Thank you! >> You must create a new chipscope icon with Disable Boundary Scan Component Instance. hta will give you an Icon with more ports than usual, these ports must be connected to the corresponding ports of the opb_mdm component (use Show ports with default connections when connecting ports)Article: 90166
Hi Ben, Thank you for your advices. Now I'll try to use coregen IPs in ISE 6.1. I cannot use the latest release of ISE (7.1.03, I mean) because it seems like it has some bugs. (I'm not sure about that. Maybe my circuit has some bugs, too.) And.. My application related to 2D graphics. Exactly it's about the self configuration of image sensor using several images but now I have too much obstacles :) Thank you so much.Article: 90167
timotoole@gmail.com schrieb: > Systolic array architectures are commonly used for image/video > compression hardware blocks (e.g. convolution filters, motion > estimation, > etc). I loosely have an idea that this is because they are efficient > at > reusing the data, and thus reduce memory accesses in comparsion to say > a > custom designed high throughput singular processing element. Would this > be generally considered the princicpal benefit and are there other > benefits? > > I have read that they are considered "i/o bandwidth efficient", I guess > thats just another way of saying what I've just outlined above? > > Is there ever scenario's where the area and switching overhead of a > systolic array would warrant a less bandwidth efficient, more serial > approach - or is that just plain ridulous to consider? In fact only the serial solution has an area and switching overhead for each computation. The systolic implementation only computes without doing anything else. See below. > For example could you hope to trade less switching in the datapath for > increased switching in the memory accesses but still make an overall > reduction in switching? If your alogrithm dictates that you add two numbers, you can not save the switching of the adder. But you might be able to save the memory access. Whenever you have an algorithm that can be implemented systolically without an increase of net operations performed (Filters, Smith-Waterman, etc.) the systolic implementation must be a lot more efficient. If you have to perform the operations anyway it is allways more efficient to perform them right away when the data is available compared to sending intermediate results a long distance across chip or even off chip. The later will slow down the process and consume a lot of power. However, this is the overall area/delay efficiency (computations per time per area). If you have a fixed bandwidth goal perfect efficiency doesn't help you much if you only have enough data available to utilize the hardware only 1% of the time. In that case you go to a more serial solution to save hardware. But the area/time/energy per computation increases in that case. More complicated are problems were the systolic algorithm requires more operations than the serial algorithm. In that case you need to tradeoff the gains per computation of the systolic implementation vs. the improved number of computations of the serial algorithm. Kolja SulimmaArticle: 90168
T. Irmen wrote: > Hi, > > i spend one week to figure out how this combination could work - with no > success. > > currently we install the rh ws 3.0 into a separate directory ; chroot to > it and start the software, that works > > I think something with the X libraries doensīt work with current amd 64 > port of debian, ise produces a segmentation fault at startup. > > does anyone have some ideas / suggestions? I've had some success at getting RH-only stuff running in Debian by using strace to watch what happens, then faking up the libraries using a bunch of symlinks. Very ugly, but with sufficient pain can be made to work. Haven't tried it with ISE, but have done it with various other tools from several vendors. > > regards, > thomas > > BTW: I know that Xilinx says:RH WS3.0 is the ONLY supported distribution. > System is dual opteron (2600MHz), 8GB mem, SATA etc... I īd like to use > debian for a lot of reasons.... And, as a fellow Debian user, I would agree with your choice. After running/administering a Debian box for a few years, going back to RH is just plain painful. - DerekArticle: 90169
one way is to simply serialize the data using LVDS.. the other is to simply replicate the input in each device the each device handles only 1/4 of the selection. Partly it depends on how/where your data is coming from. I can't tell you how to do it... you have to analyse and learn Simon "vssumesh" <vssumesh_asic@yahoo.com> wrote in message news:1128515181.357701.217050@g47g2000cwa.googlegroups.com... > I didn't understand that. How can i interconnect the huge routing > signals between the FPGA's. >Article: 90170
Hi everybody, With ASICs, there are standard cell libraries in .lib file format for the target process -- is there a comparable .lib file for the Xilinx FPGAs? Best regards, SimonArticle: 90171
You are most likely right ... but as you say.. many designers confuse the two but the effect is the same (missing samples) .. so is the cure :-) Simon "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1128523047.354410.304960@g44g2000cwa.googlegroups.com... > Simon, your problem was not metastability. Since many designers do not > really understand the metastable mechanism, it gets blamed for all > mystery problems. In many cases the problem is caused by synchronizing > an asynchronous input in more than one flip-flop in parallel. This will > inevitably fail, because the two flip-flops have different capture > times. But that has nothing whatsoever to do with metastabilty... > Peter Alfke >Article: 90172
that's a bit sad.. if someone actually did in vent perpetual motion.. and it could be proved.. he would go broke as he can't patent it ... guess I'll buy a lotto ticket instead :-( Simon "austin" <austin@xilinx.com> wrote in message news:di29fg$q3f12@xco-news.xilinx.com... > Philip, > > I always enjoy reading patents that claim to eliminate metastability. > > Seems that the patent office has never figured this one out: they did > make it a law that perpetual motion machines are not patentable, but > there is no such restriction for metastability "eliminators" (all of > which don't work!). > > Many of these clever circuits perform worse than the standard solutions > found in any good textbook on the subject, as you point out. > > Austin > > Philip Freidin wrote: > > > Hi Bill, > > > > On Tue, 4 Oct 2005 12:16:04 +0200, "Bill" <billbill@telia.se> wrote: > > > >>Is the following a good way to avoid meta stability problems? The signal 'd' > >>is synchronous to a 1.8 MHz clock? > > > > > > And from your code I assume that the synchronizing clock is > > 24 MHz. > > > > > > The answer to yor question is that your solution is NOT a good > > way to "avoid" metastability. > > > > First, you can't avoid it, you can only make its effect lower > > probability. The way to make it lower probability is to have > > additional settling time within the synchronizer. > > > > Second, while your circuit is clever, it boils down to > > a two stage synchronizer, with logic (your median circuit) > > between the first and second stage. This logic subtracts > > from the resolving time available between the first stage > > and the second stage of your synchronizer. As is often the > > case with proposed circuits to help mitigate metastability > > in clock domain crossing circuits, what you have done is > > made the analysis of the behavior harder, but the result is > > not as good as just two flipflops. > > > > Peter's response to you is dead wrong in this part: > > > >>There are more important things to worry about, forget metastability... > > > > > > in this part: > > > >>If you run a 1.8 MHz clock (even with a similar asynchronous data > >>rate), your chance of having a 3 ns extra metastable delay is once per > >>billion years (at 24 MHz it would be only 5 million years). > > > > > > the assumption of 3 ns slack is unsupported, and if you are using > > Xilinx's crappy FPGA router (you don't say which product you are > > targetting) then there may be no slack regardless of what the cycle > > time is, although as clock rates drop the likelyhood of there > > being no slack diminishes. This is because the router stops trying > > to improve the route as soon as the timing specification is met. > > At this point there is no slack. > > > > This issue can be helped by adding specific timing constraints to > > the synchronizer circuit that force additional resolving time by > > specifying path requirements that are more demanding than the > > clock cycle time implies. > > > > in this part: > > > >>For every additional ns of acceptable settling time, the > >>mean-time-between-failure increases at least a million times. (see > >>XAPP094 on the Xilinx website) > > > > > > this rule of thumb depends on what product you are using. The 1E6 > > is for the latest devices. You may be using something else. > > Older technology may have numbers as low as 1E2. > > > > In summary, you will be better served with a simple two stage > > synchronizer, with as tight a timing constraint as you can use > > to maximize the slack time between the first and second flip flops. > > > > You can read FAR more on the subject at this URL: > > > > http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm > > > > > > > >>... your VHDL ... > > > > > > > > > > Philip Freidin > > > > > > > > =================== > > Philip Freidin > > philip.freidin@fpga-faq.org > > Host for WWW.FPGA-FAQ.ORGArticle: 90173
Good morning,
I had a design wich was working fine in Libero 6.0 SP3 (Synplify
7.51A). I made an upgrade to Libero 6.2 SP2 (Synplify 8.1A).
When I open the project the conversion works fine.
Without changing anything to the vhdl files or viewdraw schematic file
I redo the synthesis with Synplify. It seems to work without problem.
I then open Designer. I get the following error message:
Error: ERROR in SECTION GLOBAL_CLOCKS near line 17 ::
DCF#023: Invalid pin Z_1I478:PAD. Pin is Ignored
Warning: The constraint data (DCF) has unavailable net/pin references.
The invalid constraints will be removed.
I did not change anything to the clock pins!
I prevent Synplify to use automatically all clock pins (HCLK, CLKA and
CLKB) for all the clocks it finds in the design by adding two attribute
lines (syn_noclockbuf...) in the vhd file created by viewdraw.
And I use a CLKBUF in viewdraw to be allowed to set my clock signal on
the CLKA pin.
I am almost certain the problem comes from Synplify because if I do
exactly the same steps but without redoing the synthesis, that is
opening Designer directly after the conversion of the project then I
get not error during the layout.
Is there maybe an option in Synplify I have to change?
Thank you very much,
Marie
Article: 90174
The warning talked about "3 NON-CLK pins" .. that's a dead giveaway for a
gated clock somewhere or using a signal which isn't a clock.... or using a
clock in a non-clock way. I would look at the circuit hard.
You might find a good option is to use a couple of SLR16's as counters for
your SPI. each can replace a number of 'loads' with a single one.
Another option is to duplicate the clock for your SPI.. I am guessing that
you are creating a clock from a system clock .. and then using it to clock
both the IO pins and the logic.
One solution is to duplicate the clock generator, the other is to ONLY use
the system clock. use a gate to latch the incoming data which is generated
in parallel to the clock not from the clock.
i.e.
spi_clock : process (rst, clk) is
begin
if (rst = '1') then
spi_clk <= '0';
spi_ce <= '0';
spi_ctr <= 0;
elsif rising_edge(clk);
spi_ctr <= (spi_ctr + 1) mod 8;
if (spi_ctr = 7) then
spi_clk <= not spi_clk;
spi_ce <= '1';
else
spi_ce <= '0';
end if;
end if;
end process spi_clock;
This gives you a clock enable pulse in parallel with the data. You might
want to delay the clock by one cycle so that the two match up edge wise, but
it will work without too much problems.
You might also want to create a positive edge and negative edge clock
enable... use one on transmit, one on receive
Note: I just made this up.. it is similar to what I use at work but I
haven't simulated it.
Simon
"Marco" <marcotoschi@nospam.it> wrote in message
news:di0hr9$oth$1@news.ngi.it...
>
> "Simon Peacock" <simon$actrix.co.nz> wrote in message
> news:4343a67a@news2.actrix.gen.nz...
> > Firstly.. a 16-bit spi peripheral is just done with two spi
transactions.
> >
>
> I tried in the past, and it didn't work. I must send a clock enable to the
> ADC, wait for 5 clock cycle and then receive 16bit. When I receive 2
> "packets" of 8 bit I loose some bits between the first and the second
> packet.
> The only way is to receive a packet of 16 bit sequentially.
>
>
> > Second.. don't use gated clocks.
> >
>
> I always have used FF with clock enable, but the clock enable now has high
> load (8-10 from report of XST synthesis).
>
> Here my trouble... I would avoid high load to clock enable
>
> > Third.. see two (can't repeat this often enough).
> >
> > Forth.. use a divide by two with a clock enable to generate the SPI
clock.
>
> I think you're talking about a dcm. I can't because the max freq.
supported
> by ADC is 2.9 MHz...
>
> In the past I tried with divide by 32 to obtain a freq. of about 1,5 MHz
>
>
> > It will clean up all your problems.
> > including sending on rising edge, receiving on falling edge. The only
> > down
> > side is it takes twice as long... so you wait 8 'busy_waits' instead of
4
> > ..
> > usually it doesn't cause a problem.
> >
> >
> > Simon
>
>
>
> Many Thanks for your answer and sorry to everyone for my bad english.
>
> Marco
>
>
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