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
Sylvain Munaut wrote: > Hi, > > > We're faced with a strange problem ... > While investigating a bug in one design, we could only observe that > behavior on real board and not in simulation. > > Using chipscope, we finally traced down the problem by monitoring > both write and read port of a FIFO16 configured as 18x1024, using the > same rd/wr clocks. That fifo was used in a "weird" way, by setting a > ALMOSTFULL threshold very high (but still within spec), so that it turn > on very quicly. And what we observed is that we push a data with some > parity bits (which are not 'true' parity but some critical control), we > continue to push, the almost full goes up (normal), and we still push > (we still have plenty of room) and at the same time we re-read but > slower (not at each clock cycle) and when we finally re-read the data > where the parity bit was set, the data (15:0) are there but the parity > bit is not, it's just 0 ... > > The chipscope 'probes' were tied directly to the fifo signals, no logic > in between. That fifo is supposed to cross clock domains but for > debugging, we just sent the same clock everywhere. And the behavior of > the surrounding logic is consitent with that bit being missed. > > Instead of using ALMOSTFULL set to a very high value, we used not > ALMOSTEMPTY (here since we're debugging with just 1 clock domain, it's > ok), and there it looks like we never observe such a miss. > > > Has someone ever observed such a behavior ? > > > > Sylvain Have you got any resolution on this? Have you opened a case with Xilinx? What does Xilinx have to say about it? I am aware that some people have had problems with the FIFO16 not working correctly. I had an issue with trying to use the FIFO as a synchronous fifo (it is async, so there is a possibility with some ambiguity on the flag latency when both clocks are the same). I have asked Xilinx repeatedly to document this behavior prominently in the user guide, but so far they have only quietly acknowledged that the user has to be careful if read and write clocks are the same. That said, your problem is different than the one I experienced and appears to be a more serious problem in the FIFO16 logic. You are not the first person I've heard state they had problems with the fifo16 async behavior. There may be some issues with the flag logic for asynchronous use as well. I do find it interesting that Altera was forthcoming with their recent problems with dual port memories. I hope that Xilinx is equally forthcoming if there is indeed a problem with the FIFO16 logic.Article: 92551
Hi Fred: I am also getting the same error. Interestingly enough, I am using the same version of ISE, same IP update, and same version of Windows XP. I've also tried Dual Port Block Mem versions 6.1 and 6.2 in the CoreGen tool and get the same error. In my application, I am targetting a VirtexII. I'm not aware of any work-arounds but also hoping someone can jump in and provide suggestions! Dean.Article: 92552
johnp wrote: > I'm using a Xilinx V2Pro part with the 6.2.03i s/w release and I'm > seeing the > following unconstrained path in the timing report: > > ================================================================================ > Timing constraint: Unconstrained period analysis for net "clk_conv" > > Delay: 3.073ns (data path - clock path skew + > uncertainty) > Source: u0clk_trig_if/trig_conv0 (FF) > Destination: u0clk_trig_if/trig_conv1 (FF) > Data Path Delay: 3.073ns (Levels of Logic = 0) > Clock Path Skew: 0.000ns > Source Clock: clk_conv rising at 0.000ns > Destination Clock: clk_conv rising at 2.450ns > Clock Uncertainty: 0.000ns > > Data Path: u0clk_trig_if/trig_conv0 to u0clk_trig_if/trig_conv1 > Location Delay type Delay(ns) Physical > Resource > Logical > Resource(s) > ------------------------------------------------- > ------------------- > SLICE_X32Y0.YQ Tcko 0.419 > u0clk_trig_if/trig_conv0 > > u0clk_trig_if/trig_conv0 > SLICE_X25Y9.BY net (fanout=2) 2.428 > u0clk_trig_if/trig_conv0 > SLICE_X25Y9.CLK Tdick 0.226 > u0clk_trig_if/trig_conv1 > > u0clk_trig_if/trig_conv1 > ------------------------------------------------- > --------------------------- > Total 3.073ns (0.645ns logic, > 2.428ns route) > (21.0% logic, > 79.0% route) > > > > In my .ucf file, I have set the period on clk_conv, so I don't see why > I'm getting this unconstrained path. In fact, in another section of the > timing > report, I see: > > ================================================================================ > Timing constraint: TS_clk_conv = PERIOD TIMEGRP "clk_conv" 2.450 nS > HIGH 50.000000 % ; > > 4 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold > errors) > > > Thus, I believe the constraint on clk_conv is entered correctly, but > for some reason > the tools appear to ignore the constraint on some of the registers > driven by the > clock. > > My Verilog code has the registers trig_conv1 and trig_conv0 in the same > always > block with the proper clock edge. The code seems straight forward, so > I don't > see how the coding style could cause this. > > > > Any ideas? > > Thanks > > John Providenza I recently encountered a case in which timing constraints were not applied to inputs of RAM16X1Ds. This was for a V4FX60 using ISE 7.1 service pack 4. I opened a web case and sent them the design to look at, and they came up with a work around for me, and filed a change request to have the problem fixed. Here is a copy of the response that explains the work around: Hi John, I have found a work around to this issue. You can manually add the missing elements into the time group in the PCF file before running PAR. 1. Open the PCF file in a text editor. 2. Locate the TIMEGRP mem_interface_top_0_infrastructure0_clk0_bufg_in 3. Add the following line: BEL ?mem_interface_top_0/main_00/top_00/user_interface_00/rd_data_00/rd_data_fifo1/ram_fall0/RAM16X1D[31].U_.WE? 4. Repeat this for each bit of the RAM that is showing up in the unconstrained section. Just remember to backup the PCF because if you re-run Map it will overwrite the file and your changes will be lost. Also, the change request number is 219222. If you need to check the status you can ping me or call the hotline number. The details are specific to what I was working on, but you should be able to modify them to fit your case. I am working on a different part of the design at the moment, so I have not tried this workaround yet. If you open a web case, refer them to case 601820, which is the one I opened. Regards, John McCaskillArticle: 92553
If there's a "sloppy timing dependence" in the design then it's one of those things that is worth fixing sooner rather than later, regardless of what tool version you're using. My comment is based on past experience.... AlanArticle: 92554
You have a couple of things to straighten out here (I didn't check your
logic for you, I just looked at a few constructs).
The biggest mistake you've made is that you mixed your logic with your
test bench. Xilinx has no way of knowing which is which since they're
both written in verilog. What you need to do is put all of your logic
(the stuff that will go into the CPLD) in one file and then instantiate
that logic in your testbench.
I'll go through a couple of problems here:
* Delays are always ignored for synthesis. They shouldn't be needed in
your logic. If they are, it is probably flawed logic, or perhaps an
ugly hack to get around some other problem.
* Initial blocks are ignored for synthesis (usually, though this is not
necessarily the case). You should use either an asynchronous reset or
a synchronous reset instead.
* The following logic is bad since it is a combinational block that
does not have all inputs declared.
/* GENERATE SCK WHEN outClock HIGH */
/* SCK = CLOCK/8 */
always @(clk) begin
if (outClock == 1) begin
sck = !sck;
#4;
end else
sck = 1;
end
For this block, you must get rid of the delays and add sck to the
sensitivity list, but this logic will still not work. You can either
have two clock domains, one for sck and one for clk, or you can make a
state machine that outputs an enable bit for other logic. For example:
reg [2:0] dly_count;
reg enable_sck;
always @ (posedge clk or negedge rst)
begin
if(!rst)
dly_count <= 3'h0;
else
begin
dly_count <= dly_count + 1;
end
end
always @(dly_count)
begin
if(dly_count == 3'b111)
enable_sck = 1'b1;
else
enable_sck = 1'b0;
end
What this logic will do (assuming I didn't make a mistake, which is
possible; it's untested) is set enable_sck high 1 clock out of every 8.
What you can then do is for all logic that uses the sck, you enable it
with the enable_sck, so for example:
//shift register that shifts on "sck"
reg [3:0] sreg;
reg shift_out;
always @ (posedge clk or negedge rst)
begin
if(!rst)
sreg <= 4'h0;
else
begin
if(enable_sck)
{shift_out,sreg} <= {sreg[3:0],shift_in};
end
end
Another mistake is perhaps the repeat command. I'm not sure that it
can be synthesized. It might be able to be by some synthesizers (I'm
amazed by the strange stuff that design compiler can synthesize), but I
would still not recommend it. In the way that you used it though, I
would never expect it to work. You can't write serialized logic the
way you did since delays are not synthesized. All of that repeat(16)
block would happen in 0 time (theoretically).
There are a lot of flaws in your design (ignoring checking actual
logic). You probably should read the XST users guide from xilinx.
It's available for free on the web. It will tell you what kinds of
logic you can synthesize and give you a good idea of good design
practices.
CPLDs and FPGAs, while not exactly like ASICs, are very similar. They
at the very least require the same methodology. Remember that this is
a digital design and not an embedded system and that there isn't really
such a thing as a "delay" in rtl and that everything should happen
synchronous to a clock.
Perhaps you should also look through some examples at fpga4fun.com to
get a better idea of what can be done with FPGAs and CPLDs. If you
have any questions though on how something works or what might be the
best way of writing something (out of several possibilities that you
have written), please post back here at comp.arch.fpga. Folks are
pretty helpful when it comes to specific questions.
Good Luck,
Arlen
Article: 92555Ray, The bug for use of the async FIFO synchronously has been acknolwedged, and we apologize for not getting it out there more prominently. But: In our defense, it is unusual (or at least, so far we think it is unusual) where the read and write clocks are tied directly together (why use a FIFO at all? I guess it is a really useful structure, so even when used this way it is too useful to ignore....?). The solution is to not source the two clocks from the same source directly, but place a small delay in one, or the other. The problem does not exist in the asynchronous case, as it takes two subsequent clock cycles on BOTH clocks (at exactly the wrong times) to cause the problem. As long as the probability of two adjacent clock cyles not coming in on both clocks exactly the same just as you are getting full (or is it empty? I'm not the expert on this), it works fine. Sometimes with problems like this (that are difficult to even cause) it doesn't make sense to put up a billboard that it is an issue, as then everyone comes down with the disease (mass hypochrondira) when they don't really have the problem. Now, if the feature is just plain broke, then it is a different story, and we will end the pain as soon as we are sure it is just plain broke. No one is intentionally hiding anything, but we are judiciously placing (obscure) bug information only with the hotline and support community, rather than broadcasting it across the entire user community publicy. If, for any reason, you feel that you have caught the disease (have a bug we haven't shared universally), the entry of a webcase will get you the help you need, as the hotline will search for all such issues. If yours is there, then we will immediately share with you the solution. These are known as "internal answers" and it isn't that we don't want to share them, we just don't think they are likely issues for everyone. Better to talk to you and find out what the problem is, first. If these internal answers are made external, we imagine there would be thousands of designers running down debug paths that are so obscure, there is almost no chance they will find this as their problem. Then we get a bad reputation, and the hotline is overwhelmed with folks who all think they have this obscure problem! I hope folks will appreciate that sometimes telling every strange and obscure story causes more trouble than selectively understanding each issue that arises, and dealing with it directly. Support: it is an art. Austin Ray Andraka wrote: > Sylvain Munaut wrote: > >> Hi, >> >> >> We're faced with a strange problem ... >> While investigating a bug in one design, we could only observe that >> behavior on real board and not in simulation. >> >> Using chipscope, we finally traced down the problem by monitoring >> both write and read port of a FIFO16 configured as 18x1024, using the >> same rd/wr clocks. That fifo was used in a "weird" way, by setting a >> ALMOSTFULL threshold very high (but still within spec), so that it turn >> on very quicly. And what we observed is that we push a data with some >> parity bits (which are not 'true' parity but some critical control), we >> continue to push, the almost full goes up (normal), and we still push >> (we still have plenty of room) and at the same time we re-read but >> slower (not at each clock cycle) and when we finally re-read the data >> where the parity bit was set, the data (15:0) are there but the parity >> bit is not, it's just 0 ... >> >> The chipscope 'probes' were tied directly to the fifo signals, no logic >> in between. That fifo is supposed to cross clock domains but for >> debugging, we just sent the same clock everywhere. And the behavior of >> the surrounding logic is consitent with that bit being missed. >> >> Instead of using ALMOSTFULL set to a very high value, we used not >> ALMOSTEMPTY (here since we're debugging with just 1 clock domain, it's >> ok), and there it looks like we never observe such a miss. >> >> >> Has someone ever observed such a behavior ? >> >> >> >> Sylvain > > > Have you got any resolution on this? Have you opened a case with > Xilinx? What does Xilinx have to say about it? > > I am aware that some people have had problems with the FIFO16 not > working correctly. I had an issue with trying to use the FIFO as a > synchronous fifo (it is async, so there is a possibility with some > ambiguity on the flag latency when both clocks are the same). I have > asked Xilinx repeatedly to document this behavior prominently in the > user guide, but so far they have only quietly acknowledged that the user > has to be careful if read and write clocks are the same. > > That said, your problem is different than the one I experienced and > appears to be a more serious problem in the FIFO16 logic. You are not > the first person I've heard state they had problems with the fifo16 > async behavior. There may be some issues with the flag logic for > asynchronous use as well. > > I do find it interesting that Altera was forthcoming with their recent > problems with dual port memories. I hope that Xilinx is equally > forthcoming if there is indeed a problem with the FIFO16 logic. >Article: 92556
Peter's explanation on how to implement a FIFO cannot be improved much, if any - this is how FIFOs are implemented in hard- and software. Here is an alternative to building your own FIFO out of RAM - has worked for me more than once. If the purpose is to have the FIFO (and not to build it, say, for learning or economic purposes), you can use one of the 72XX (IDT used to make them) FIFO chips. They have the R/W pointer circuitry inside etc., really convenient to use - and you will need no memory address lines out of the FPGA, nor will the data necessarily go through it (that is, you can just handle the full/empty flags and the R/W strobes - and there also is a half full flag). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 92557
I'm trying to build a simple ALU with an adder/subtracter unit and I need both carry and overflow outputs to set the appropriate flags. However, CoreGen (6.3) doesn't let me have both carry and overflow outputs. I really don't understand why. Xilinx designers should think twice before limiting their users in such a stupid way. Just because you don't see why someone would want both outputs, doesn't mean that somebody won't find an application that may require them. If you think that doesn't make sense, fine; that's what we have warnings for. Warn me that the value of overflow is meaningless for unsigned numbers, but don't prevent me from using it. For instance, in this case, I don't know whether the user will add/subtract signed or unsigned numbers!!! It's up to them to decide, and then it's up to them to look into the appropriate flag. Except that I can't provide that flag using this core. Now I have to do it manually, which will most likely be less efficient. And then I'll compare it with Altera's LPM, which will of course be more efficient. Frustrated, Fred P.S. For those that don't believe that this is the case, you can see it for yourself in the following document: http://www.xilinx.com/ipcenter/catalog/logicore/docs/addsub.pdf (Table 2)Article: 92558
I so love it when people give advice that the original poster has already acknowledged is not needed, instead of answering the question that was posed! I'm also interested in downloading the older versions for performance comparison purposes. Can someone now answer the original question, or is performance comparison across software versions also a bad idea. BTW, in my experience, Altera's licenses cover all versions of software released before the expiry date.Article: 92559
Peter Alfke wrote: > The Virtex-2 family that you are referring to is very much alive, and > is the best-selling family in Xilinx history. Remember, the newly > introduced families are "better", more capable, and faster, but the > bulk of our shipments is obviously into systems that have reached > production status and were designed a few years ago. > For today's design-starts, the designers must carefully evaluate > whether the older families are "good enough" or whether the better > features and sometimes lower price of the newer family are more > important. Peter, We all know that for new designs, new parts should be considered. But all Dave was asking was if he could buy the parts. It's likely that he's got an existing design in production, and a redesign (and possible requalification, etc) is not an option. -aArticle: 92560
Well, as I said: "it's our best selling family". That means it is very much available. I would guess that you will be able to buy it from Xilinx and our distributors for at least another five years. Is that enough? Peter Alfke, Xilinx ApplicationsArticle: 92561
Dave Roberts wrote: > I think these parts may be obsolete. I can't find any suppliers in the USA. > I need package type FG456. Does anyone know where I can buy them? > > Thanks, > > Dave. Avnet website shows that they have some XC2V250-6FG456C parts in stock. They also have some variant of the XC2V1000 in FG456 in stock. www.em.avnet.com and search, or: http://tinyurl.com/ey78n Regards, John McCaskillArticle: 92562
Reza - The first thing you must understand about Verilog is that some of its constructs are synthesizable, other are not. These latter constructs such as 'while', 'repeat', 'wait', 'initial' are in the language purely for simulation. These constructs cannot be synthesized. So you need to learn what constructs can be used for designing your CPLD and which ones can only be used in the testbench. Next, you need to separate the testbench code from the CPLD logic. In the testbench, instantiate the actual design. When you want to synthesize, only give XST the actual design to work on, not the design and testbench. Next, you need to understand about logic design, ie, how do flip flops really work, how to do synchronous design for timing analysis, etc. You should look at some examples of other peoples work. Try Opencores.org. Good luck! John ProvidenzaArticle: 92563
kedarpapte@gmail.com wrote:
> I tried many was of implementing this combi structure in Altera Stratix
> but glitch is still there.
> Any guideline or suggetions will be greatly helpful...
I would suggest eliminating glitches using synchronous
design techniques and verifying Fmax using Quartus static timing.
-- Mike Treseler
Article: 92564Austin, You are kidding as far as the usefulness of a synchronous fifo (one which has both sides clocked by the same clock), right? This is a rather common structure in pipelined designs, it is an elastic buffer. Useful, for example, for processing bursty data at a more relaxed rate than the data is presented. I'd be hard pressed to find one of my designs that does NOT have a synchronous FIFO in it. The solution with the "small" delay is fine if you are not pushing the performance envelope, but it will destroy timing closure in designs that are. For example, I have a floating point FFT design with a target clock rate of 400 MHz in an SX55-10 part... basically running at the DSP48/memory speed. It has synchronous FIFOs in it, and there is no room in the timing for adding small delays to clocks. This is a real limitation to the FIFO16 design, and has cost me several weeks of debug and redesign time to find and work around it. It should be prominently highlighted in the user guide under the section that describes the used of the FIFO16. I am sure other users are going to encounter the same issue. No one looks at the answers database until they have a problem and have identified the source of the problem. The synchronous FIFO issue could easily be considered a limitation rather than an outright bug, but it does have to be made clear to the user before he does the design, not when trying to figure out why it isn't working. By keeping it close to your chest as an internal answer, I suspect you'll wind up generating a heck of a lot more hotline cases than if you put it in black and white right in the user's guide that this is the way the FIFO16's work and that these are the things you need to do to work around the limitation if the clocks are the same on both sides. BTW, I don't think this is an "obscure" issue either, as anyone attempting to use the FIFO16 as a synchronous FIFO is going to encounter it. The flip answers regarding the synchronous FIFO (things like such a structure is not useful, and just add delays to the clock when I've explained that it is not a viable solution for maximum performance designs), combined with the reluctance to make it clear to users that this is a limitation of the FIFO16 design, makes it appear that either Xilinx doesn't understand the issue or that they are trying to sweep it under the rug. I presume and hope it is the former, although neither is a particularly good outcome. I am reluctant to enter a webcase on an issue such as this unless it has become critical for the project. Invariably, the result of entering a webcase is my having to generate and submit testcases to prove the problem, and often having to come up with my own work-around because the fix won't be available until the next major release. Nobody pays me for the time spent doing testcases to ferret out the source of a bug in the software or silicon. There have been months recently where I've spent more than a quarter of my time identifying and generating test cases for problems in the tools (not just Xilinx). Naturally, I'd like to avoid that as much as practical. Regarding the asynchronous FIFO behavior, I don't have any direct experience with the FIFO16 behaving badly as an async FIFO, But I haven't used it in that mode in a design that has made it to testing. Silvain's description does sound as though the FIFO may be misbehaving, and it jives with things I've heard from others. This is why I asked him if he had opened a case with Xilinx and what the resolution of that case was. It is important to know if there is a potential problem so that I can avoid it during the design rather than discover it during integration. I am currently working on a design that has several async FIFO16's in it, and would like to believe that they will work for me, however these rumblings have me concerned, hence my asking Sylvain about his resolution. So far, the work arounds I am aware of have used the coregen FIFO instead of the FIFO16, which does not have the same clock performance as the FIFO16. I didn't intend to kick over the beehive here, I was only trying to collect more data so that I might avoid a problem in my own design if it does exist. Austin Lesea wrote: > Ray, > > The bug for use of the async FIFO synchronously has been acknolwedged, > and we apologize for not getting it out there more prominently. But: > > In our defense, it is unusual (or at least, so far we think it is > unusual) where the read and write clocks are tied directly together (why > use a FIFO at all? I guess it is a really useful structure, so even > when used this way it is too useful to ignore....?). > > The solution is to not source the two clocks from the same source > directly, but place a small delay in one, or the other. > > The problem does not exist in the asynchronous case, as it takes two > subsequent clock cycles on BOTH clocks (at exactly the wrong times) to > cause the problem. As long as the probability of two adjacent clock > cyles not coming in on both clocks exactly the same just as you are > getting full (or is it empty? I'm not the expert on this), it works fine. > > Sometimes with problems like this (that are difficult to even cause) it > doesn't make sense to put up a billboard that it is an issue, as then > everyone comes down with the disease (mass hypochrondira) when they > don't really have the problem. > > Now, if the feature is just plain broke, then it is a different story, > and we will end the pain as soon as we are sure it is just plain broke. > > No one is intentionally hiding anything, but we are judiciously placing > (obscure) bug information only with the hotline and support community, > rather than broadcasting it across the entire user community publicy. > > If, for any reason, you feel that you have caught the disease (have a > bug we haven't shared universally), the entry of a webcase will get you > the help you need, as the hotline will search for all such issues. If > yours is there, then we will immediately share with you the solution. > > These are known as "internal answers" and it isn't that we don't want to > share them, we just don't think they are likely issues for everyone. > Better to talk to you and find out what the problem is, first. > > If these internal answers are made external, we imagine there would be > thousands of designers running down debug paths that are so obscure, > there is almost no chance they will find this as their problem. Then we > get a bad reputation, and the hotline is overwhelmed with folks who all > think they have this obscure problem! > > I hope folks will appreciate that sometimes telling every strange and > obscure story causes more trouble than selectively understanding each > issue that arises, and dealing with it directly. > > Support: it is an art. > > Austin > > > Ray Andraka wrote: > >> Sylvain Munaut wrote: >> >>> Hi, >>> >>> >>> We're faced with a strange problem ... >>> While investigating a bug in one design, we could only observe that >>> behavior on real board and not in simulation. >>> >>> Using chipscope, we finally traced down the problem by monitoring >>> both write and read port of a FIFO16 configured as 18x1024, using the >>> same rd/wr clocks. That fifo was used in a "weird" way, by setting a >>> ALMOSTFULL threshold very high (but still within spec), so that it turn >>> on very quicly. And what we observed is that we push a data with some >>> parity bits (which are not 'true' parity but some critical control), we >>> continue to push, the almost full goes up (normal), and we still push >>> (we still have plenty of room) and at the same time we re-read but >>> slower (not at each clock cycle) and when we finally re-read the data >>> where the parity bit was set, the data (15:0) are there but the parity >>> bit is not, it's just 0 ... >>> >>> The chipscope 'probes' were tied directly to the fifo signals, no logic >>> in between. That fifo is supposed to cross clock domains but for >>> debugging, we just sent the same clock everywhere. And the behavior of >>> the surrounding logic is consitent with that bit being missed. >>> >>> Instead of using ALMOSTFULL set to a very high value, we used not >>> ALMOSTEMPTY (here since we're debugging with just 1 clock domain, it's >>> ok), and there it looks like we never observe such a miss. >>> >>> >>> Has someone ever observed such a behavior ? >>> >>> >>> >>> Sylvain >> >> >> >> Have you got any resolution on this? Have you opened a case with >> Xilinx? What does Xilinx have to say about it? >> >> I am aware that some people have had problems with the FIFO16 not >> working correctly. I had an issue with trying to use the FIFO as a >> synchronous fifo (it is async, so there is a possibility with some >> ambiguity on the flag latency when both clocks are the same). I have >> asked Xilinx repeatedly to document this behavior prominently in the >> user guide, but so far they have only quietly acknowledged that the >> user has to be careful if read and write clocks are the same. >> >> That said, your problem is different than the one I experienced and >> appears to be a more serious problem in the FIFO16 logic. You are not >> the first person I've heard state they had problems with the fifo16 >> async behavior. There may be some issues with the flag logic for >> asynchronous use as well. >> >> I do find it interesting that Altera was forthcoming with their recent >> problems with dual port memories. I hope that Xilinx is equally >> forthcoming if there is indeed a problem with the FIFO16 logic. >>Article: 92565
Nanditha - You rock! Thanks, that solved that issue and has allowed me to simulate the sample test of the Aurora core. Now I'm trying to incorporate a Coregen created Aurora core into an existing project, but it doesn't seem to like me doing this. I have an existing project in ISE and I add the <aurora_core>.xco. Whenever I try to view the HDL Functional Model it regenerates the core but does not display the HDL. Whenever I double click on Manage Core, it invokes Coregen but then says that my device is not the virtex-4 and thus does not have the Aurora Core. The specific error is: ERROR:sim:160 - Could not find requested IP (Aurora,2.3) for currently selected part. I go to project options and it displays that my device is not virtex-4 but Automotive Coolrunner2. I change it to the correct device, but this does nothing. Any idea why this is? Also, I've noticed in the sample_test of the Aurora core that it uses the GT11_custom instantiation. This leads me to believe that if I use a GT11_custom core via Architect Wizard and have the attributes match those of the Aurora Core it would work in the same fashion. Is this true? Thanks again for all your help! JPArticle: 92566
juendme@yahoo.com wrote: > I'm trying to build a simple ALU with an adder/subtracter unit and I > need both carry and overflow outputs to set the appropriate flags. > However, CoreGen (6.3) doesn't let me have both carry and overflow > outputs. I really don't understand why. > > Xilinx designers should think twice before limiting their users in such > a stupid way. Just because you don't see why someone would want both > outputs, doesn't mean that somebody won't find an application that may > require them. If you think that doesn't make sense, fine; that's what > we have warnings for. Warn me that the value of overflow is meaningless > for unsigned numbers, but don't prevent me from using it. > > For instance, in this case, I don't know whether the user will > add/subtract signed or unsigned numbers!!! It's up to them to decide, > and then it's up to them to look into the appropriate flag. Except that > I can't provide that flag using this core. Now I have to do it > manually, which will most likely be less efficient. And then I'll > compare it with Altera's LPM, which will of course be more efficient. > > Frustrated, > > Fred > > P.S. > > For those that don't believe that this is the case, you can see it for > yourself in the following document: > http://www.xilinx.com/ipcenter/catalog/logicore/docs/addsub.pdf (Table > 2) I use ISE-WebPack, so I guess I don't have CoreGen. I'm still just out of the VHDL newbie stage, but if I understand the document's table #2, it doesn't look like CoreGen will build an adder/subtractor that handles _both_ signed and unsigned data. At least I didn't see a "pin" that tells the logic to treat the data as signed or unsigned. If all that's true, it looks like you'll have to roll your own. -Dave PollumArticle: 92567
Ray, your comments are again right on target with my own feelings about bugs
and support. The webcase submission issue especially hits home. One minor
difference for me may be that when I find unusual behavior and have it
isolated to a functional portion of the design, I may check the (externally
available) knowledge database for any information relating to my problem
area before spending a few more days to further isolate the cause. I've had
several instances where the information is in *a* database, just not one I
can get to.
For ANYONE who is concerned with whether or not to air the dirty laundry of
their EDA tools and silicon, PLEASE read through Ray's note and understand
where designers come from. Our company has had TOO many issues with silicon
(non-FPGA as well) and EDA tools ("you knew about this for how many
months?") that when we encounter known bugs that are "hidden" from plain
view, we are LIVID. There is no excuse to withhold information that WILL
affect designs if there is a way to communicate the issues externally.
In this instance, there is a way.
"Ray Andraka" <ray@andraka.com> wrote in message
news:LlIjf.15740$Mi5.7070@dukeread07...
> Austin,
>
> You are kidding as far as the usefulness of a synchronous fifo (one which
> has both sides clocked by the same clock), right? This is a
> rather common structure in pipelined designs, it is an elastic buffer.
> Useful, for example, for processing bursty data at a more relaxed rate
> than the data is presented. I'd be hard pressed to find one of my designs
> that does NOT have a synchronous FIFO in it. The solution with the
> "small" delay is fine if you are not pushing the performance envelope, but
> it will destroy timing closure in designs that are. For example, I have a
> floating point FFT design with a target clock rate of 400 MHz in an
> SX55-10 part... basically running at the DSP48/memory speed. It has
> synchronous FIFOs in it, and there is no room in the timing for adding
> small delays to clocks. This is a real limitation to the FIFO16 design,
> and has cost me several weeks of debug and redesign time to find and work
> around it. It should be prominently highlighted in the user guide under
> the section that describes the used of the FIFO16. I am sure other users
> are going to encounter the same issue. No one looks at the answers
> database until they have a problem and have identified the source of the
> problem. The synchronous FIFO issue could easily be considered a
> limitation rather than an outright bug, but it does have to be made clear
> to the user before he does the design, not when trying to figure out why
> it isn't working. By keeping it close to your chest as an internal answer,
> I suspect you'll wind up generating a heck of a lot more hotline cases
> than if you put it in black and white right in the user's guide that this
> is the way the FIFO16's work and that these are the things you need to do
> to work around the limitation if the clocks are the same on both sides.
> BTW, I don't think this is an "obscure" issue either, as anyone attempting
> to use the FIFO16 as a synchronous FIFO is going to encounter it.
>
> The flip answers regarding the synchronous FIFO (things like such a
> structure is not useful, and just add delays to the clock when I've
> explained that it is not a viable solution for maximum performance
> designs), combined with the reluctance to make it clear to users that this
> is a limitation of the FIFO16 design, makes it appear that either Xilinx
> doesn't understand the issue or that they are trying to sweep it under the
> rug. I presume and hope it is the former, although neither is a
> particularly good outcome.
>
> I am reluctant to enter a webcase on an issue such as this unless it has
> become critical for the project. Invariably, the result of entering a
> webcase is my having to generate and submit testcases to prove the
> problem, and often having to come up with my own work-around because the
> fix won't be available until the next major release. Nobody pays me for
> the time spent doing testcases to ferret out the source of a bug in the
> software or silicon. There have been months recently where I've spent
> more than a quarter of my time identifying and generating test cases for
> problems in the tools (not just Xilinx). Naturally, I'd like to avoid
> that as much as practical.
>
> Regarding the asynchronous FIFO behavior, I don't have any direct
> experience with the FIFO16 behaving badly as an async FIFO, But I haven't
> used it in that mode in a design that has made it to testing.
> Silvain's description does sound as though the FIFO may be misbehaving,
> and it jives with things I've heard from others. This is why I asked him
> if he had opened a case with Xilinx and what the resolution of that case
> was. It is important to know if there is a potential problem so that I
> can avoid it during the design rather than discover it during integration.
> I am currently working on a design that has several async FIFO16's in it,
> and would like to believe that they will work for me, however these
> rumblings have me concerned, hence my asking Sylvain about his resolution.
> So far, the work arounds I am aware of have used the coregen FIFO instead
> of the FIFO16, which does not have the same clock performance as the
> FIFO16.
>
> I didn't intend to kick over the beehive here, I was only trying to
> collect more data so that I might avoid a problem in my own design if it
> does exist.
>
>
>
>
>
> Austin Lesea wrote:
>> Ray,
>>
>> The bug for use of the async FIFO synchronously has been acknolwedged,
>> and we apologize for not getting it out there more prominently. But:
>>
>> In our defense, it is unusual (or at least, so far we think it is
>> unusual) where the read and write clocks are tied directly together (why
>> use a FIFO at all? I guess it is a really useful structure, so even when
>> used this way it is too useful to ignore....?).
>
>
>>
>> The solution is to not source the two clocks from the same source
>> directly, but place a small delay in one, or the other.
>>
>> The problem does not exist in the asynchronous case, as it takes two
>> subsequent clock cycles on BOTH clocks (at exactly the wrong times) to
>> cause the problem. As long as the probability of two adjacent clock
>> cyles not coming in on both clocks exactly the same just as you are
>> getting full (or is it empty? I'm not the expert on this), it works fine.
>>
>> Sometimes with problems like this (that are difficult to even cause) it
>> doesn't make sense to put up a billboard that it is an issue, as then
>> everyone comes down with the disease (mass hypochrondira) when they don't
>> really have the problem.
>>
>> Now, if the feature is just plain broke, then it is a different story,
>> and we will end the pain as soon as we are sure it is just plain broke.
>>
>> No one is intentionally hiding anything, but we are judiciously placing
>> (obscure) bug information only with the hotline and support community,
>> rather than broadcasting it across the entire user community publicy.
>>
>> If, for any reason, you feel that you have caught the disease (have a bug
>> we haven't shared universally), the entry of a webcase will get you the
>> help you need, as the hotline will search for all such issues. If yours
>> is there, then we will immediately share with you the solution.
>>
>> These are known as "internal answers" and it isn't that we don't want to
>> share them, we just don't think they are likely issues for everyone.
>> Better to talk to you and find out what the problem is, first.
>>
>> If these internal answers are made external, we imagine there would be
>> thousands of designers running down debug paths that are so obscure,
>> there is almost no chance they will find this as their problem. Then we
>> get a bad reputation, and the hotline is overwhelmed with folks who all
>> think they have this obscure problem!
>>
>> I hope folks will appreciate that sometimes telling every strange and
>> obscure story causes more trouble than selectively understanding each
>> issue that arises, and dealing with it directly.
>>
>> Support: it is an art.
>>
>> Austin
>>
>>
>> Ray Andraka wrote:
>>
>>> Sylvain Munaut wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> We're faced with a strange problem ...
>>>> While investigating a bug in one design, we could only observe that
>>>> behavior on real board and not in simulation.
>>>>
>>>> Using chipscope, we finally traced down the problem by monitoring
>>>> both write and read port of a FIFO16 configured as 18x1024, using the
>>>> same rd/wr clocks. That fifo was used in a "weird" way, by setting a
>>>> ALMOSTFULL threshold very high (but still within spec), so that it turn
>>>> on very quicly. And what we observed is that we push a data with some
>>>> parity bits (which are not 'true' parity but some critical control), we
>>>> continue to push, the almost full goes up (normal), and we still push
>>>> (we still have plenty of room) and at the same time we re-read but
>>>> slower (not at each clock cycle) and when we finally re-read the data
>>>> where the parity bit was set, the data (15:0) are there but the parity
>>>> bit is not, it's just 0 ...
>>>>
>>>> The chipscope 'probes' were tied directly to the fifo signals, no logic
>>>> in between. That fifo is supposed to cross clock domains but for
>>>> debugging, we just sent the same clock everywhere. And the behavior of
>>>> the surrounding logic is consitent with that bit being missed.
>>>>
>>>> Instead of using ALMOSTFULL set to a very high value, we used not
>>>> ALMOSTEMPTY (here since we're debugging with just 1 clock domain, it's
>>>> ok), and there it looks like we never observe such a miss.
>>>>
>>>>
>>>> Has someone ever observed such a behavior ?
>>>>
>>>>
>>>>
>>>> Sylvain
>>>
>>>
>>>
>>> Have you got any resolution on this? Have you opened a case with
>>> Xilinx? What does Xilinx have to say about it?
>>>
>>> I am aware that some people have had problems with the FIFO16 not
>>> working correctly. I had an issue with trying to use the FIFO as a
>>> synchronous fifo (it is async, so there is a possibility with some
>>> ambiguity on the flag latency when both clocks are the same). I have
>>> asked Xilinx repeatedly to document this behavior prominently in the
>>> user guide, but so far they have only quietly acknowledged that the user
>>> has to be careful if read and write clocks are the same.
>>>
>>> That said, your problem is different than the one I experienced and
>>> appears to be a more serious problem in the FIFO16 logic. You are not
>>> the first person I've heard state they had problems with the fifo16
>>> async behavior. There may be some issues with the flag logic for
>>> asynchronous use as well.
>>>
>>> I do find it interesting that Altera was forthcoming with their recent
>>> problems with dual port memories. I hope that Xilinx is equally
>>> forthcoming if there is indeed a problem with the FIFO16 logic.
>>>
Article: 92568Thanks for the excellent help. Though now I'm quite irritated at the $80 verilog book that I bought - it didn't differentiate at all between the constructs that are test-bench specific, and the ones that I could use for the design. It also didn't indicate any problems with using delays in the code. And most all that code except the part labeled 'TEST CLOCK' is all supposed to be functional logic to be implemented. So it sounds like I'll have to re-write the whole thing. I'll look at some of the sites you referred me to. I also dont mind buying another book on the subject if you have any recommendations. Thanks! Reza p.s. I'll be posting again soonArticle: 92569
John, Ray,
I never said, nor implied we would intentionally withhold information.
That is bad. Really bad.
I understand that you may consider our choice of distribution of
information (through answers externally available, or through answers
internally available to case workers and FAEs) to be unacceptable.
I will entertain any other solutions. One that I might suggest is that
you sign up for a push email whenever something happens that you
indicate you are interested in. Maybe its been tried, maybe not. I
know we do have push email systems in place now. Perhaps we need to add
features?
As far as async FIFO issues go, I am getting some emails on that subject
as well. So, even though I thought (and witnessed) the extensive FIFO
testing on V4, the problem with a test that passes is that a test is
never the application.
I will reserve a whole-hearted endorsement of perfection until I hear
more about what the alleged issues are with async mode.
And Ray, I appreciate the use of the FIFO synchronously (toungue firmly
in cheek comments), I just never thought about it before. Making an
async FIFO is so much black magic that you spend all your time looking
at the async case, and no time with the sync case (obviously the problem
here).
Austin
John_H wrote:
> Ray, your comments are again right on target with my own feelings about bugs
> and support. The webcase submission issue especially hits home. One minor
> difference for me may be that when I find unusual behavior and have it
> isolated to a functional portion of the design, I may check the (externally
> available) knowledge database for any information relating to my problem
> area before spending a few more days to further isolate the cause. I've had
> several instances where the information is in *a* database, just not one I
> can get to.
>
> For ANYONE who is concerned with whether or not to air the dirty laundry of
> their EDA tools and silicon, PLEASE read through Ray's note and understand
> where designers come from. Our company has had TOO many issues with silicon
> (non-FPGA as well) and EDA tools ("you knew about this for how many
> months?") that when we encounter known bugs that are "hidden" from plain
> view, we are LIVID. There is no excuse to withhold information that WILL
> affect designs if there is a way to communicate the issues externally.
>
> In this instance, there is a way.
>
>
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:LlIjf.15740$Mi5.7070@dukeread07...
>
>>Austin,
>>
>>You are kidding as far as the usefulness of a synchronous fifo (one which
>>has both sides clocked by the same clock), right? This is a
>>rather common structure in pipelined designs, it is an elastic buffer.
>>Useful, for example, for processing bursty data at a more relaxed rate
>>than the data is presented. I'd be hard pressed to find one of my designs
>>that does NOT have a synchronous FIFO in it. The solution with the
>>"small" delay is fine if you are not pushing the performance envelope, but
>>it will destroy timing closure in designs that are. For example, I have a
>>floating point FFT design with a target clock rate of 400 MHz in an
>>SX55-10 part... basically running at the DSP48/memory speed. It has
>>synchronous FIFOs in it, and there is no room in the timing for adding
>>small delays to clocks. This is a real limitation to the FIFO16 design,
>>and has cost me several weeks of debug and redesign time to find and work
>>around it. It should be prominently highlighted in the user guide under
>>the section that describes the used of the FIFO16. I am sure other users
>>are going to encounter the same issue. No one looks at the answers
>>database until they have a problem and have identified the source of the
>>problem. The synchronous FIFO issue could easily be considered a
>>limitation rather than an outright bug, but it does have to be made clear
>>to the user before he does the design, not when trying to figure out why
>>it isn't working. By keeping it close to your chest as an internal answer,
>>I suspect you'll wind up generating a heck of a lot more hotline cases
>>than if you put it in black and white right in the user's guide that this
>>is the way the FIFO16's work and that these are the things you need to do
>>to work around the limitation if the clocks are the same on both sides.
>>BTW, I don't think this is an "obscure" issue either, as anyone attempting
>>to use the FIFO16 as a synchronous FIFO is going to encounter it.
>>
>>The flip answers regarding the synchronous FIFO (things like such a
>>structure is not useful, and just add delays to the clock when I've
>>explained that it is not a viable solution for maximum performance
>>designs), combined with the reluctance to make it clear to users that this
>>is a limitation of the FIFO16 design, makes it appear that either Xilinx
>>doesn't understand the issue or that they are trying to sweep it under the
>>rug. I presume and hope it is the former, although neither is a
>>particularly good outcome.
>>
>>I am reluctant to enter a webcase on an issue such as this unless it has
>>become critical for the project. Invariably, the result of entering a
>>webcase is my having to generate and submit testcases to prove the
>>problem, and often having to come up with my own work-around because the
>>fix won't be available until the next major release. Nobody pays me for
>>the time spent doing testcases to ferret out the source of a bug in the
>>software or silicon. There have been months recently where I've spent
>>more than a quarter of my time identifying and generating test cases for
>>problems in the tools (not just Xilinx). Naturally, I'd like to avoid
>>that as much as practical.
>>
>>Regarding the asynchronous FIFO behavior, I don't have any direct
>>experience with the FIFO16 behaving badly as an async FIFO, But I haven't
>>used it in that mode in a design that has made it to testing.
>>Silvain's description does sound as though the FIFO may be misbehaving,
>>and it jives with things I've heard from others. This is why I asked him
>>if he had opened a case with Xilinx and what the resolution of that case
>>was. It is important to know if there is a potential problem so that I
>>can avoid it during the design rather than discover it during integration.
>>I am currently working on a design that has several async FIFO16's in it,
>>and would like to believe that they will work for me, however these
>>rumblings have me concerned, hence my asking Sylvain about his resolution.
>>So far, the work arounds I am aware of have used the coregen FIFO instead
>>of the FIFO16, which does not have the same clock performance as the
>>FIFO16.
>>
>>I didn't intend to kick over the beehive here, I was only trying to
>>collect more data so that I might avoid a problem in my own design if it
>>does exist.
>>
>>
>>
>>
>>
>>Austin Lesea wrote:
>>
>>>Ray,
>>>
>>>The bug for use of the async FIFO synchronously has been acknolwedged,
>>>and we apologize for not getting it out there more prominently. But:
>>>
>>>In our defense, it is unusual (or at least, so far we think it is
>>>unusual) where the read and write clocks are tied directly together (why
>>>use a FIFO at all? I guess it is a really useful structure, so even when
>>>used this way it is too useful to ignore....?).
>>
>>
>>>The solution is to not source the two clocks from the same source
>>>directly, but place a small delay in one, or the other.
>>>
>>>The problem does not exist in the asynchronous case, as it takes two
>>>subsequent clock cycles on BOTH clocks (at exactly the wrong times) to
>>>cause the problem. As long as the probability of two adjacent clock
>>>cyles not coming in on both clocks exactly the same just as you are
>>>getting full (or is it empty? I'm not the expert on this), it works fine.
>>>
>>>Sometimes with problems like this (that are difficult to even cause) it
>>>doesn't make sense to put up a billboard that it is an issue, as then
>>>everyone comes down with the disease (mass hypochrondira) when they don't
>>>really have the problem.
>>>
>>>Now, if the feature is just plain broke, then it is a different story,
>>>and we will end the pain as soon as we are sure it is just plain broke.
>>>
>>>No one is intentionally hiding anything, but we are judiciously placing
>>>(obscure) bug information only with the hotline and support community,
>>>rather than broadcasting it across the entire user community publicy.
>>>
>>>If, for any reason, you feel that you have caught the disease (have a bug
>>>we haven't shared universally), the entry of a webcase will get you the
>>>help you need, as the hotline will search for all such issues. If yours
>>>is there, then we will immediately share with you the solution.
>>>
>>>These are known as "internal answers" and it isn't that we don't want to
>>>share them, we just don't think they are likely issues for everyone.
>>>Better to talk to you and find out what the problem is, first.
>>>
>>>If these internal answers are made external, we imagine there would be
>>>thousands of designers running down debug paths that are so obscure,
>>>there is almost no chance they will find this as their problem. Then we
>>>get a bad reputation, and the hotline is overwhelmed with folks who all
>>>think they have this obscure problem!
>>>
>>>I hope folks will appreciate that sometimes telling every strange and
>>>obscure story causes more trouble than selectively understanding each
>>>issue that arises, and dealing with it directly.
>>>
>>>Support: it is an art.
>>>
>>>Austin
>>>
>>>
>>>Ray Andraka wrote:
>>>
>>>
>>>>Sylvain Munaut wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>
>>>>>We're faced with a strange problem ...
>>>>>While investigating a bug in one design, we could only observe that
>>>>>behavior on real board and not in simulation.
>>>>>
>>>>>Using chipscope, we finally traced down the problem by monitoring
>>>>>both write and read port of a FIFO16 configured as 18x1024, using the
>>>>>same rd/wr clocks. That fifo was used in a "weird" way, by setting a
>>>>>ALMOSTFULL threshold very high (but still within spec), so that it turn
>>>>>on very quicly. And what we observed is that we push a data with some
>>>>>parity bits (which are not 'true' parity but some critical control), we
>>>>>continue to push, the almost full goes up (normal), and we still push
>>>>>(we still have plenty of room) and at the same time we re-read but
>>>>>slower (not at each clock cycle) and when we finally re-read the data
>>>>>where the parity bit was set, the data (15:0) are there but the parity
>>>>>bit is not, it's just 0 ...
>>>>>
>>>>>The chipscope 'probes' were tied directly to the fifo signals, no logic
>>>>>in between. That fifo is supposed to cross clock domains but for
>>>>>debugging, we just sent the same clock everywhere. And the behavior of
>>>>>the surrounding logic is consitent with that bit being missed.
>>>>>
>>>>>Instead of using ALMOSTFULL set to a very high value, we used not
>>>>>ALMOSTEMPTY (here since we're debugging with just 1 clock domain, it's
>>>>>ok), and there it looks like we never observe such a miss.
>>>>>
>>>>>
>>>>>Has someone ever observed such a behavior ?
>>>>>
>>>>>
>>>>>
>>>>> Sylvain
>>>>
>>>>
>>>>
>>>>Have you got any resolution on this? Have you opened a case with
>>>>Xilinx? What does Xilinx have to say about it?
>>>>
>>>>I am aware that some people have had problems with the FIFO16 not
>>>>working correctly. I had an issue with trying to use the FIFO as a
>>>>synchronous fifo (it is async, so there is a possibility with some
>>>>ambiguity on the flag latency when both clocks are the same). I have
>>>>asked Xilinx repeatedly to document this behavior prominently in the
>>>>user guide, but so far they have only quietly acknowledged that the user
>>>>has to be careful if read and write clocks are the same.
>>>>
>>>>That said, your problem is different than the one I experienced and
>>>>appears to be a more serious problem in the FIFO16 logic. You are not
>>>>the first person I've heard state they had problems with the fifo16
>>>>async behavior. There may be some issues with the flag logic for
>>>>asynchronous use as well.
>>>>
>>>>I do find it interesting that Altera was forthcoming with their recent
>>>>problems with dual port memories. I hope that Xilinx is equally
>>>>forthcoming if there is indeed a problem with the FIFO16 logic.
>>>>
>
>
>
Article: 92570Hi Ray, Ray Andraka wrote: > Have you got any resolution on this? Have you opened a case with > Xilinx? What does Xilinx have to say about it? My colleague had some contact with our distributor but afaik, no news yet. Looking at the xilinx answer record , I saw that fifo usign FIFO16 blocks generated with an old version of fifogenerator could show some datacorruption problem and that usage of the new one is recommanded ... but I didn't use coregenerator, i instanciated FIFO16 directly (coregen doesn't have first word fall thru anyway ...) I haven't opened a webcase myself yet, ... often before "bothering" xilinx peoples, I want to be sure ;p I've tried to reproduce the problem with a far simpler design but so far no luck ... (even in the full design it's quite "rare" but 1 times suffice to lock it ...) > I am aware that some people have had problems with the FIFO16 not > working correctly. I had an issue with trying to use the FIFO as a > synchronous fifo (it is async, so there is a possibility with some > ambiguity on the flag latency when both clocks are the same). I have > asked Xilinx repeatedly to document this behavior prominently in the > user guide, but so far they have only quietly acknowledged that the user > has to be careful if read and write clocks are the same. What exactly is the problem if the clocks are the same ? (what behaviour could happen ?) > That said, your problem is different than the one I experienced and > appears to be a more serious problem in the FIFO16 logic. You are not > the first person I've heard state they had problems with the fifo16 > async behavior. There may be some issues with the flag logic for > asynchronous use as well. Well, here we use the fifo synchronously ... They are meant in the future to be used asynchronously but for testing, we've put everything at the same clock. But other part in the design will always use them synchronously so I must get it working in both mode ... SylvainArticle: 92571
Austin Lesea wrote: > Ray, > > The bug for use of the async FIFO synchronously has been acknolwedged, > and we apologize for not getting it out there more prominently. But: Where can I get detailled infos about it ? (to be sure not to run into it, or at least that it doesn't cause trouble in my design ?) SylvainArticle: 92572
Such pins do exist (see Table 1.; signals A_SIGNED and B_SIGNED), although I have no idea what exactly those signal do (thanks to incomplete documentation). Because if you look into any digital design textbook, you'll see that the adder/subtracter circuit is exactly the same for both signed and unsigned numbers. The only difference is that carry is not an indication of the error in the result for signed numbers, but you need overflow. And going back to table 2, what are the 2 extra bits in the result (P=Q+2) in rows 2 and 3? Carry and ....? Could it be overflow? But then why isn't P=Q+2 an option when both inputs are signed? Xilinx, thanks for incomplete and confusing documentation! In contrast, Altera's lpm_add_sub readily provides both carry and overflow outputs. It also provides a parameter to specify whether the numbers are signed or unsigned, and explains what effect that paramter has on the operation of the circuit (it only affects the behavior of the overflow output, nothing else).Article: 92573
Sylvain, I expect the fastest way is to open a webcase requesting the information. As I already stated, if both read and write clocks are from the same BUFG net, then this may (will) probably be an issue at some process/voltage/temperature corner (hence the indsidiousness of the issue). A quick fix is to drive one of the clocks from the other edge (one rising, one falling) which may require another BUFG resource (in order to be sure the delay doesn't put you right back where you started). It is my understanding that a macro will be created to instantiate the sync FIFO with the required offset delay automatically in the best way we can (probably using fabric resources, like a LUT, doubles, hexes, etc.). The issue as I was told is that at the critical instant, the almost full/almost empty flag assertions will be correct, but if the event occurs again on the very next clock cycle, the flag will reset to 0, which will not be correct (as the FIFO is still almost full, or almost empty if nothing was done to read anything out, or write anything in on that cycle). There may be other simpler solutions (that we haven't thought of yet). Again, the jury is out on the async case.... Austin Sylvain Munaut wrote: > Austin Lesea wrote: > >>Ray, >> >>The bug for use of the async FIFO synchronously has been acknolwedged, >>and we apologize for not getting it out there more prominently. But: > > > Where can I get detailled infos about it ? (to be sure not to run into > it, or at least that it doesn't cause trouble in my design ?) > > > > SylvainArticle: 92574
Sylvain Munaut wrote: > Austin Lesea wrote: > >>Ray, >> >>The bug for use of the async FIFO synchronously has been acknolwedged, >>and we apologize for not getting it out there more prominently. But: > > > Where can I get detailled infos about it ? (to be sure not to run into > it, or at least that it doesn't cause trouble in my design ?) > > > > Sylvain This is exactly what I mean by the problem being hidden. I searched the answers database for FIFO16, and did not turn up anything regarding the known synchronous behavior problem, nor any async problems. It may still only be in the internal database, if it is even there. In debugging stuff like this, I've always assumed the silicon is good and that any problems are a result of the design until I can prove otherwise. As a result, you don't suspect the FIFO itself as being the problem. That can lead to a tremendous amount of debugging effort before finding out there is a problem or unpublished limitation with the silicon. Considering how much time I spent fiddling with this problem, I suspect there are literally thousands of manhours put into debugging the same problem in different projects simply because Xilinx doesn't want to advertise a limitation with their design. The problem with the synchronous usage is that the flag circuit is an async design. When the clock is the same to both sides, and a read and write are done on the same clock cycle, the flag circuit displays a one clock jitter in the timing of the flag outputs, such that the word written in at the same time the last one is read out may or may not make the fifo show empty. If empty does get set, it then takes something like 3 clocks to go away, so you wind up with a non-deterministic behavior. It is an artifact of using an async flag circuit. BTW, finding stuff in the answers database is a lot like finding a needle in a haystack, provided you even know what you are looking for.
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