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
I think your intuition is correct. Be brave and go with the star topology with the idea of minimizing the length of the longest leg. As I'm sure you understand, when the traces are short relative to the edge rate then you don't have to fuss with impedance control/buffers which is easily done wrong anyway. And you are correct about the sim, only meaningful with correct board impedance data, too much finess required. Regards rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C965C25.974C5512@yahoo.com>... > This is one that I will test in simulation, but I don't hold much hope > for it to work well. I found an article from Howard Johnson on the web > about designing T routes. It showed that this could be made to work, > but that it was not easy. Splitting the trace four ways, would make it > very hard to do. Just adding a series resistor is not magic. It is > there to match the source impedance to the trace. Then where the trace > splits, the outbound traces need to have a higher impedance to prevent a > discontinuity. > > I have not looked up the formula for trace impedances, but HJ made it > sound like they would get pretty narrow to bring the impedance up enough > to match. In this case it would need to be about 200 Ohms after a four > way split if you had 50 ohms before the split. I guess I could use a > very small resistor, or no resistor, at the output of the chip. This > would give me an impedance less than 50 Ohms and would allow the traces > after the split to be somewhat wider. > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > One problem with any analysis is the lack of good data. One data point > I am lacking is the rise time of the clock. In this case I need to know > the minium rise time since this is the worst case. The maximum is 2 nS, > so it may be reasonable to assume 1 nS as a typical value. > > > > Pete Dudley wrote: > > > > I would think about doing the star routing with a source termination > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > same length and make sure there are no breaks in the ground return under > > these legs. > > > > -- > > Pete Dudley > > > > Arroyo Grande Systems > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:3C923297.57531263@yahoo.com... > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if > > > you keep it square (as layout guys like to do). The other signals are > > > within the box these two points inscribe. > > > > > > Another approach would be to daisy chain them which would make the total > > > run about 3 inches. What type of termination could I expect to work > > > well with this type of run? > > > > > > With such short runs, I was thinking about using no termination with a > > > star topology. I am not even sure I need to worry about keeping the net > > > delays equal since the variation will be less than +- 1 inch or about > > > 100 pS of clock skew. > > > > > > Anyone have much experience with running high speed clocks on such short > > > runs? Can I expect this to work well? > > > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > > just trying to get a "gut" feeling as Bob Pease would want to do. You > > > know how easy it is to get the WRONG, right answer from a computer. > > > GIGO. > > > > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41001
Hi, we have been working with xlinx xc4010xl trying to implement a subtracter using fast carry logic. the following error occured: ERROR:OldMap:455 - The signal `GLOBAL_LOGIC0' on the CIN pin of CY4 symbol "XLXI_13" (output signal=XLXN_15) is a constant logic1 or logic0. Initially the signal was inappropriately driven by a logic1/0 constant comp. Use one of the FORCE-x modes to initiate a carry chain CIN signal. 1. How can we initiate the carry chain correctly? we tried using a force-x mode as well as a sub-g-1 mode, leaving cin unwired... 2. Does anyone know of a detailed (code or schematic) example of how to use the carry logic including the relevant rlocs? Thanks a lot Thorsten and ThomasArticle: 41002
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> writes: > Other people recommended instantiating two designs in one top module, > and run both of them from a top module. > I guess your idea will be to XOR the outputs coming from the two modules > to see when they won't match. > I guess that is possible in theory, but I rather see both waveforms > untouched myself. You can still dump the entire hierarchy from the DUTs and below (I would include the compare module as well) so both your waveforms will be untouched. I usually sample the outputs and do a plain compare far out in the cycle. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 41003
sjmeyer@www.tdl.com (Steve Meyer) writes: > One way to do the comparing is to add the P1364 standard dumpvars > feature by adding call "$dumpvars" to the design source (preferably at time > 0 or if you do not want to compare results until a given time, at the at > that time). The first simulation will write verilog.dump file. After > simulation runs, copy file to other name and run model to compare again > with added $dumpvars. Then just use diff command to compare results. Clever! Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 41004
Petter Gustad <newsmailcomp1@gustad.com> writes: > Design Acceleration (now part of Cadence) has a product called > comparescan for this purpose. Comparing waveforms that is, not instantiating the two DUTs. With signalscan (waveform viewer) you can easily open two TRN (trace files generated by the signalscan PLI routines or converted from VCD) from two different simulations. You can also specify an event search to find where they differ. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 41005
Further thoughts, In the hallway, Peter asked me about the "virtual" grounds (using unused IOs as ground pins. As a result of our discussion, here is some more information. Here is what we have found and seen through our testing, and have suggested to customers: 1. An unused pin is effective in reducing the jitter on an input pin by as much as three to five times if used as a ground pin. Program the IOB to be a strong driver, driving a '0'. Connect the pin to ground externally. More than one pin used this way adds very little benefit past the first one used. 2. Unused pins, when spaced through a large wide bus, can reduce the ground bounce by as much as 1/2 if they are programmed to be '0' and connected to ground externally. Placing unused pins as virtual grounds at the edges of a wide bus do almost nothing at all for any of the signals inside the bus. Austin Austin Lesea wrote: > Manfred, > > All good recommendations. > > I wish to reinforce the comment about sharp transistions on clocks: a sine > wave clock is easily influenced by adjacent switching noise, and can lead to > excessive jitter. Cross coupling from adjacent pcb traces will cause cross > talk induced delay variations (jitter), and any ground bounce from SSOs will > also cause jitter. > > Good signal integrity, using matched IOs to trace impedances, and excellent > bypassing are all required. > > Remember that the period constraint must be reduced by 1/2 of the total peak to > peak jitter if you expect to meet your timing. Now that we routinely have > clocks of 100 to 300 MHz, the usually ignored jitter is now a significant > factor. > > Austin > > Manfred Kraus wrote: > > > > I am designing a general I/O board with a Virtex II (xcv2V3000 to 8000) > > and > > > some memory. I have about 100 spare pins. I have read on the newsgroups > > > sometime ago that it was good to connect them to ground an to assign a > > value > > > to each of them. > > > Did anybody went through this problem yet ? > > > > Leave them open and unconfigured. > > You may also drive them as outputs with constant levels > > if you think that would be better. > > Using them as "auxiliary GND" pins like it was > > recommended for the good old XC73000 CPLD > > is not required. > > > > > Also, an external clock will be connected directly to the FPGA. The range > > is > > > 0-200 MHz. I assume it requires a input filter between the connector and > > the > > > FPGA. I thought about a low pass filter with a cut frequency of 200 MHz. > > > Does it sound good ? > > > > Dont use a filter with clock signals, you might not get valid high and low > > levels > > any more. The edge of your clock signal will also not be sharp any more. > > Your clock signal will look like a sine curve. > > If you use the correct impedance for > > the termination and the PCB routes everything will be fine. > > Of course you need connectors that are good for 200MHz. > > One more thing: if your input clock is garbage, there will be no easy > > solution > > to restore it. > > > > -Manfred KrausArticle: 41006
Austin Lesea wrote > 1. An unused pin is effective in reducing the jitter on an input pin by as much as > three to five times if used as a ground pin. Program the IOB to be a strong > driver, driving a '0'. Connect the pin to ground externally. More than one pin > used this way adds very little benefit past the first one used. An unused immediately adjacent pin (neighbours on the die) ? Or just within a few pads?Article: 41007
Austin, Thank you for the information. I think I will need to hit the books again to digest the information, especially about the part when output is going to a PLL and how it prefers high freq content. Once again, thanks for taking time out of your busy day to answer question on the news group! Sincerely, Jon HoArticle: 41008
If I faced the unusual luxury of several ( or many ) unused pins, I would do the following: • Surround the most jitter-critical clock input with a grounded pin on either side. That eliminates crosstalk at the package entrance. Of course, it does nothing to existing crosstalk from the pc-board. •Sprinkle virtual grounds between critical output bus lines, to reduce ground bounce. "Virtual grounds" are strong, permanently active Low outputs that are externally directly connected to the ground plane. Each kind of a surrogate extra ground pin. • I would also keep a few pins free for potentially poking around in the chip. Unfortunately, this luxury is rare :-( Peter Alfke, Xilinx Applications ========================= Tim wrote: > Austin Lesea wrote > > 1. An unused pin is effective in reducing the jitter on an input pin by as > much as > > three to five times if used as a ground pin. Program the IOB to be a strong > > driver, driving a '0'. Connect the pin to ground externally. More than one > pin > > used this way adds very little benefit past the first one used. > > An unused immediately adjacent pin (neighbours on the die) ? > > Or just within a few pads?Article: 41009
Tim, Within two or three pads is plenty good. Adjacent pad is best. Austin Tim wrote: > Austin Lesea wrote > > 1. An unused pin is effective in reducing the jitter on an input pin by as > much as > > three to five times if used as a ground pin. Program the IOB to be a strong > > driver, driving a '0'. Connect the pin to ground externally. More than one > pin > > used this way adds very little benefit past the first one used. > > An unused immediately adjacent pin (neighbours on the die) ? > > Or just within a few pads?Article: 41010
The DDS is pretty easy to do:
library ieee;
use ieee.numeric_std.all;
use ieee.std_logic_1164.all;
entity dds is
generic(
bits:natural);
port(
clk: in std_logic;
inc: out std_logic_vector;
clk_out: out std_logic);
end dds;
architecture RTL of dds is
signal accum unsigned(bits-1 downto 0);
begin
process(clk)
begin
if clk'event and clk='1' then
accum<=accum+unsigned(inc);
end if;
end process;
clk_out<=accum(bits-1);
end RTL;
Salman Sheikh wrote:
> Yes, Xilinx has a core function that implements a DDS in their ISE 4.1 software.
>
> Salman
>
> On 19 Mar 2002 03:24:13 -0800
> mister_mot@hotmail.com (Mot) wrote:
>
> > Does any of you know some sites where I can view examples of DDS
> > inplemented in an FPGA?
> >
> > thx mot
>
> --
> Salman Sheikh
> NASA/GSFC Code 564
> Greenbelt, MD 20771
> 301-286-3763 301-286-0220 (fax)
Article: 41011Hi, > I'm curious. What does "learning about FPGA implementation" > mean to you? Are you top-down type designer? Are you trying > to teach how to use HDLs with FPGAs as compared to how to > get the best performance out of an FPGA? That is right. The course that is being considered is a CAD course, one that is trying to teach students how CAD tools work, what kind of optimizations they can apply etc. On the research side, we have a CAD group that is developing algorithms for scheduling DSP dataflow graphs to hardware. Because of the above factors, our immediate interest is not in getting the best performance possible out of the FPGA. Using EDA tools rather than hand-polishing the design is therefore more important in our context. > > I'm a bottom-up person. I want to know the grubby details, > and the tricks for taking advantage of them - pipelining, > duplicating logic, floorplanning... Yes, it certainly appears from what I have seen that in any real-world design, the best designs require quite a deep knowledge of the system to extract the maximum performance. The idea behind our research (basically high-level synthesis) is to abstract out such knowledge into parametrizable libraries if possible, and then use higher level optimizers to put designs together. This makes it easier for designers to worry about the big-picture rather than the details, hopefully making the designs better. Regards, NitinArticle: 41012
Rick - A few comments/observations: 1) If your board stackup is at all conventional, trace impedances will fall somewhere in the range of 45 to 65 ohms. You can, with effort, get other impedances, but getting to 200 ohms will require tricks that you won't want to play. 2) I don't know the strength of the C6711 clock driver. If it's strong enough to drive a Thevenin-equivalent parallel termination, and if you can tolerate the inevitable clock skew that arises from daisy-chaining the clock net, then use a single net and parallel termination. But be sure to check the weak/slow corner clock buffer drive. In my experience, the clock outputs of processor chips tend to be underpowered. (And they can be glitchy, too; a ground-bounce-related glitch on the clock output of TI's TMS320C31 nearly torpedoed one project I worked on.) 3) If (2) doesn't pan out, spring for one of the small zero-delay buffers, and drive each clock load with its own PLL output. If the zero-delay buffer has built-in series termination, great; if not, series-terminate each output. It'll cost you (not much) space and (not much) money. I never try to economize on either when generating and distributing clocks. Bob Perlman Cambrian Design Works http://www.cambriandesign.com rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C965C25.974C5512@yahoo.com>... > This is one that I will test in simulation, but I don't hold much hope > for it to work well. I found an article from Howard Johnson on the web > about designing T routes. It showed that this could be made to work, > but that it was not easy. Splitting the trace four ways, would make it > very hard to do. Just adding a series resistor is not magic. It is > there to match the source impedance to the trace. Then where the trace > splits, the outbound traces need to have a higher impedance to prevent a > discontinuity. > > I have not looked up the formula for trace impedances, but HJ made it > sound like they would get pretty narrow to bring the impedance up enough > to match. In this case it would need to be about 200 Ohms after a four > way split if you had 50 ohms before the split. I guess I could use a > very small resistor, or no resistor, at the output of the chip. This > would give me an impedance less than 50 Ohms and would allow the traces > after the split to be somewhat wider. > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > One problem with any analysis is the lack of good data. One data point > I am lacking is the rise time of the clock. In this case I need to know > the minium rise time since this is the worst case. The maximum is 2 nS, > so it may be reasonable to assume 1 nS as a typical value. > > > > Pete Dudley wrote: > > > > I would think about doing the star routing with a source termination > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > same length and make sure there are no breaks in the ground return under > > these legs. > > > > -- > > Pete Dudley > > > > Arroyo Grande Systems > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:3C923297.57531263@yahoo.com... > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if > > > you keep it square (as layout guys like to do). The other signals are > > > within the box these two points inscribe. > > > > > > Another approach would be to daisy chain them which would make the total > > > run about 3 inches. What type of termination could I expect to work > > > well with this type of run? > > > > > > With such short runs, I was thinking about using no termination with a > > > star topology. I am not even sure I need to worry about keeping the net > > > delays equal since the variation will be less than +- 1 inch or about > > > 100 pS of clock skew. > > > > > > Anyone have much experience with running high speed clocks on such short > > > runs? Can I expect this to work well? > > > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > > just trying to get a "gut" feeling as Bob Pease would want to do. You > > > know how easy it is to get the WRONG, right answer from a computer. > > > GIGO. > > > > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41013
Many thanks to all those who responded for some excellent suggestions. We have been able to get some very interesting possibilities to search more deeply on. Thanks again, Nitin ECE Dept. Univ. of MarylandArticle: 41014
I'm stumped. I have a design that was synthesized using Synplify and P&R using Xilinx Foundation ISE 4.1. I am now trying to synthesize the design using FPGA Express and Xilinx ISE 4.2. The target device is a VirtexE1000. The trouble is with the UCF file syntax. After finally changing the case, changing the way buses are defined (ex. data(1) vs. data<1>), and changing the way INST's were referenced (ex. INST U2/U0/U2/ LOC = DLL0P; vs INST U2_U0_U2 LOC = DLL0P;) I can get all but 4 constraints to process. The last 4 I'm having trouble with are of the form: (Synplify Syntax) NET clk_1 PERIOD = 35.714 ; With these, ISE can never find the specified NET. So, how do I specify the NET name? What syntax do I use, especially if it's not in the top level module? Thanks for any help, DaveArticle: 41015
Austin - I agree; I think that more digital designers should include signal simulation in their bag of tricks. Unfortunately, there are some roadblocks to getting these simulations running. For one thing, the quality of IBIS models is iffy at best. The folks at SiQual, a signal integrity consulting firm in the northwest, recently published a paper titled, "A Critique of IBIS Models Available for Download on the Web." They concluded that 70% of the IBIS models produced warnings or errors when processed, and that 40% had serious problems, i.e., problems severe enough to prevent the simulator from using the model, or severe enough to produce erroneous results. The paper's available at www.siqual.com. And I've encountered other IBIS problems that wouldn't even result in a warning. In particular, I've seen more than a few models where it was abundantly clear that the best- and worst-case IV curves were identical to or little different from the nominal curves (and these were not controlled-impedance drivers). I'm not knocking Xilinx models, by the way; I've had pretty good luck with the more recent ones. The point I'm getting to is that being able to run simulations isn't enough; the person running them needs a good BS detector to ferret out mistakes in the model or in the simulation setup. I've seen engineers run simulations that gave good results that they believed, despite the fact that those results were clearly contrary to real life. This is the point that Bob Pease was making when he had someone photograph him lining the bottom of a birdcage with Spice printouts. Bob Perlman Cambrian Design Works http://www.cambriandesign.com Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C968CA1.43FAD089@xilinx.com>... > Rick, > > The only thing that surprises me is how many people want an 'easy' solution, and > are unwilling to simulate it. > > Once you simulate it, all mysteries are gone, the lights come on, the sun shines, > well, you get the idea. > > Once simulated, the only issues that can go wrong are: pcb isn't fabricated per > the print, device models are completely wrong. Since those are pretty unlikely > (at least for most reputable IC vendors and pcb houses) you are pretty safe. > > Austin > > rickman wrote: > > > I found another article that discusses the issue of splitting a signal > > and driving stubs. It is at > > http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm. > > > > Here Dr Howard Johnson (HJ) shows the need for series terminators at the > > receivers to damp resonance oscillations. I was surprised by this. > > > > rickman wrote: > > > > > > This is one that I will test in simulation, but I don't hold much hope > > > for it to work well. I found an article from Howard Johnson on the web > > > about designing T routes. It showed that this could be made to work, > > > but that it was not easy. Splitting the trace four ways, would make it > > > very hard to do. Just adding a series resistor is not magic. It is > > > there to match the source impedance to the trace. Then where the trace > > > splits, the outbound traces need to have a higher impedance to prevent a > > > discontinuity. > > > > > > I have not looked up the formula for trace impedances, but HJ made it > > > sound like they would get pretty narrow to bring the impedance up enough > > > to match. In this case it would need to be about 200 Ohms after a four > > > way split if you had 50 ohms before the split. I guess I could use a > > > very small resistor, or no resistor, at the output of the chip. This > > > would give me an impedance less than 50 Ohms and would allow the traces > > > after the split to be somewhat wider. > > > > > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > > > > > One problem with any analysis is the lack of good data. One data point > > > I am lacking is the rise time of the clock. In this case I need to know > > > the minium rise time since this is the worst case. The maximum is 2 nS, > > > so it may be reasonable to assume 1 nS as a typical value. > > > > > > Pete Dudley wrote: > > > > > > > > I would think about doing the star routing with a source termination > > > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > > > same length and make sure there are no breaks in the ground return under > > > > these legs. > > > > > > > > -- > > > > Pete Dudley > > > > > > > > Arroyo Grande Systems > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41016
Bob, That is really too bad. Maybe people should consider buying more Xilinx FPGAs? We are constantly striving to improve our models, and I in the lab confirm the model accuracy on a regular basis. Recently, for a Virtex II Pro simualrion, the engineer came back to me, and was astonished, as the scope picture looked exactly like what he had built on the bench. Without good models, customers will never succeed. Austin Bob Perlman wrote: > Austin - > > I agree; I think that more digital designers should include signal > simulation in their bag of tricks. > > Unfortunately, there are some roadblocks to getting these simulations > running. For one thing, the quality of IBIS models is iffy at best. > The folks at SiQual, a signal integrity consulting firm in the > northwest, recently published a paper titled, "A Critique of IBIS > Models Available for Download on the Web." They concluded that 70% of > the IBIS models produced warnings or errors when processed, and that > 40% had serious problems, i.e., problems severe enough to prevent the > simulator from using the model, or severe enough to produce erroneous > results. The paper's available at www.siqual.com. > > And I've encountered other IBIS problems that wouldn't even result in > a warning. In particular, I've seen more than a few models where it > was abundantly clear that the best- and worst-case IV curves were > identical to or little different from the nominal curves (and these > were not controlled-impedance drivers). I'm not knocking Xilinx > models, by the way; I've had pretty good luck with the more recent > ones. > > The point I'm getting to is that being able to run simulations isn't > enough; the person running them needs a good BS detector to ferret out > mistakes in the model or in the simulation setup. I've seen engineers > run simulations that gave good results that they believed, despite the > fact that those results were clearly contrary to real life. This is > the point that Bob Pease was making when he had someone photograph him > lining the bottom of a birdcage with Spice printouts. > > Bob Perlman > Cambrian Design Works > http://www.cambriandesign.com > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C968CA1.43FAD089@xilinx.com>... > > Rick, > > > > The only thing that surprises me is how many people want an 'easy' solution, and > > are unwilling to simulate it. > > > > Once you simulate it, all mysteries are gone, the lights come on, the sun shines, > > well, you get the idea. > > > > Once simulated, the only issues that can go wrong are: pcb isn't fabricated per > > the print, device models are completely wrong. Since those are pretty unlikely > > (at least for most reputable IC vendors and pcb houses) you are pretty safe. > > > > Austin > > > > rickman wrote: > > > > > I found another article that discusses the issue of splitting a signal > > > and driving stubs. It is at > > > http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm. > > > > > > Here Dr Howard Johnson (HJ) shows the need for series terminators at the > > > receivers to damp resonance oscillations. I was surprised by this. > > > > > > rickman wrote: > > > > > > > > This is one that I will test in simulation, but I don't hold much hope > > > > for it to work well. I found an article from Howard Johnson on the web > > > > about designing T routes. It showed that this could be made to work, > > > > but that it was not easy. Splitting the trace four ways, would make it > > > > very hard to do. Just adding a series resistor is not magic. It is > > > > there to match the source impedance to the trace. Then where the trace > > > > splits, the outbound traces need to have a higher impedance to prevent a > > > > discontinuity. > > > > > > > > I have not looked up the formula for trace impedances, but HJ made it > > > > sound like they would get pretty narrow to bring the impedance up enough > > > > to match. In this case it would need to be about 200 Ohms after a four > > > > way split if you had 50 ohms before the split. I guess I could use a > > > > very small resistor, or no resistor, at the output of the chip. This > > > > would give me an impedance less than 50 Ohms and would allow the traces > > > > after the split to be somewhat wider. > > > > > > > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > > > > > > > One problem with any analysis is the lack of good data. One data point > > > > I am lacking is the rise time of the clock. In this case I need to know > > > > the minium rise time since this is the worst case. The maximum is 2 nS, > > > > so it may be reasonable to assume 1 nS as a typical value. > > > > > > > > Pete Dudley wrote: > > > > > > > > > > I would think about doing the star routing with a source termination > > > > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > > > > same length and make sure there are no breaks in the ground return under > > > > > these legs. > > > > > > > > > > -- > > > > > Pete Dudley > > > > > > > > > > Arroyo Grande Systems > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41017
I am a poor ISE WebPACK 4.1 user, so I can only dream of using Synplify,
but like you, I am experiencing a problem with ISE WebPACK's synthesis
tool XST (Xilinx Synthesis Technology) synthesizing code in a way I
don't want it to.
The problem is I intentionally used only one OE FF for a 32-bit data
bus, but XST instead duplicates the OE FF 32 times . . ., so that each
OE FF can be merged inside an IOB . . .
If I wanted the OE FFs merged into IOBs, I will manually duplicate them
in my code, but I chose not to do so.
Attaching "keep" attribute doesn't seem to help either.
If interested, you can do a Google Groups search on "XST duplicates
unnecessary IOB OE FFs" (that's the title).
In that posting, Hamish Moffatt who uses Synplify told me that up to
earlier versions (6.0.x, 6.1.x) Synplify didn't duplicate the OE FF, but
the newer versions duplicates it automatically.
He thinks Synplify duplicating an OE FF automatically is not a big issue
(Yeah, until the problem is your own, it is not a big issue I guess.),
but I find this automatic duplication of an OE FF a big issue because
like your problem with Synplify reordering a tri-state buffer, the
synthesis tool is ignoring the designer's intention, and overriding it
with what it thinks is correct.
Please, synthesis tools (XST and Synplify), just convert whatever code
is given even if it doesn't make much sense, or something is not being
done in an optimal way.
Although I don't know what Synplify is like it, but it seems to
me that software companies want to keep adding more new features just to
get people to upgrade, but often times those new features are things no
one wants.
Can't software people just stop at some point if the QoR is already
pretty good?
It seems to me that Aki's Tri-state push through across boundaries issue
is a good example of software companies going too far, and ruining a
tool that's already as good as it gets.
Sort of an off topic question from a poor XST user, but is
Synplify that better than XST?
How much does Synplify cost (I am told around $10K), and is QoR that
much better justifying the price tag?
I am not questioning anyone's common sense for buying (licensing)
Synplify, but just want to know why professionals really seem to like
the tool.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41018"Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> schrieb im Newsbeitrag news:a788pe$9q7$1@newsreader.mailgate.org... > I am a poor ISE WebPACK 4.1 user, so I can only dream of using Synplify, > but like you, I am experiencing a problem with ISE WebPACK's synthesis > tool XST (Xilinx Synthesis Technology) synthesizing code in a way I > don't want it to. > The problem is I intentionally used only one OE FF for a 32-bit data > bus, but XST instead duplicates the OE FF 32 times . . ., so that each > OE FF can be merged inside an IOB . . . Hmm, this thread is going on for a while and I didnt feel to say somthing. Until now. Kevin, why do you complain about this.? With XST doing so, a) Tco is getting better b) you dont loose any FlipFlop, since the IOB FF are "free" anyway. > If I wanted the OE FFs merged into IOBs, I will manually duplicate them > in my code, but I chose not to do so. So there are command line/GUI settings that allows this. But you have to know how to handle your tools. And AKAIK, a VHDL compiler isnt a tamagotchi?? ;-)) Regards FalkArticle: 41019
"Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag news:3C978F3A.9FC0BF58@xilinx.com... > . I would also keep a few pins free for potentially poking around in the chip. > > Unfortunately, this luxury is rare :-( NOOO, since we have the 1500 Pin BGA from Xilinx (and even a 1900 Pins BGA from ALTERA) SCNR. ;-)) -- MfG FalkArticle: 41020
Either supply technology will work but your choice will depend on other parameters such as heat, available current in the 3.3 and 5v supplies, cost, complexity, etc. The buck converter is more expensive and complex than a linear although the suppliers of these chips provide excellent example circuits. The linear solution will use more than twice the power (and heat) of the switching one. You won't drop enough voltage in the layout to matter because you will be using power planes. Regards "news.dlr.de" <Holger.Venus@dlr.de> wrote in message news:<a77ide$gf$1@news.go.dlr.de>... > Hello all, > I am designing a VIRTEX-II board running at up to 80 MHz. > I use the 1M gates FF896 housed devices but prepared the layout for > FF1152 6M gates device. > There are several parallel operating data paths doing image processing. > How should I prepare the 1.5V core voltage? > There are operation modes which need some watts. > That means, the power supply has to deliver several amperes > (voltage drop over layout??). > My power source could be 3.3V or 5V of the cPCI backplane. > > Is a linear converter OK? > Is a step down converter recommended? > Are there reference designs available on the net? > > Thank you for your support. > > Holger VenusArticle: 41021
You'd have to design the PCB from the beginning to be able to switch back and forth which by the way might be a great strategy for getting price breaks from Xilinx and Altera. Ray Andraka <ray@andraka.com> wrote in message news:<3C97509A.E5F32428@andraka.com>... > There are no pin-compatible devices going from one to the other. The good news is that you are only stuck until you respin the board ;-) > > Greg Otto wrote: > > > Are there any Xilinx Spartan FPGAs that are pin compatible with Altera 10k50v-208 parts ? I designed a board initially with the 10k50v parts, but I have had so many problems with Altera, so I would like to drop a Xilinx device on the pads instead. Is there any hope, or am I stuck forever with Altera ?Article: 41022
On Tue, 19 Mar 2002 08:27:24 GMT, William Lenihan <lenihan3we@earthlink.net> wrote: > >These JTAG pods have attachments called "flying leads", where end >#1 is a fixed connector to plug into the pod (i.e., JTAG row of pins) >and >end #2 is the actual flying leads to connect to the target hardware. > >That's great for prototype & engineering development, but for >production, the actual >flying leads @ end #2 can easily be mis-placed by technicians on the >assembly >line. If you make the connector on the target match the Xilinx arrangement, you can turn the cable around and connect the flying leads end to the Xilinx pod once, and thus have a fixed 9 pin connector to plug into the target. JohnArticle: 41023
No it isn't. Why explicitly one hot encode your verilog in the year 2002? Let the synthesizer do it for you and enjoy the maintainabily benefits of readable code. Regards wreg <sdafj@ierjg.zklxv> wrote in message news:<ee759b4.-1@WebX.sUN8CHnE>... > usually,i write state machine according the following style. > isn't it? > ************************************ > `define Present_Crs_State 4:1 > `define C_Idle 1 > `define C_Rxdv 2 > `define C_Wait 3 > `define C_Togg 4 > //restore signal state machine > assign State_Rxdv = Present_Crs_State[`C_Rxdv]; > assign State_Wait = Present_Crs_State[`C_Wait]; > assign State_Togg = Present_Crs_State[`C_Togg]; > > always @(posedge RefClk50 or negedge Rst_N ) > begin > if (!Rst_N) > Present_Crs_State <= 4'b0001; > else > Present_Crs_State <= Next_Crs_State; > end > always @ ( Present_Crs_State or > Crsdv > ) > begin > Next_Crs_State = 4'b0000 ; > case (1'b1) //synopsys parallel_case full_case > Present_Crs_State[`C_Idle]: > begin > if (Crsdv&&!Rx_Disable) > Next_Crs_State[`C_Rxdv] = 1; > else > Next_Crs_State[`C_Idle] = 1; > end > Present_Crs_State[`C_Rxdv]: > begin > if (Crsdv) > Next_Crs_State[`C_Rxdv] = 1; > else > Next_Crs_State[`C_Wait] = 1; > end > Present_Crs_State[`C_Wait]: > begin > if (Crsdv) > Next_Crs_State[`C_Togg] = 1; > else > Next_Crs_State[`C_Idle] = 1; > end > Present_Crs_State[`C_Togg]: > begin > if (Crsdv) > Next_Crs_State[`C_Idle] = 1; > else > Next_Crs_State[`C_Wait] = 1; > end > default: > Next_Crs_State[`C_Idle] = 1; > endcase > endArticle: 41024
Dave, Many people will have two entries in their constraints file to do this.<br>They'll often do: NET <hierarchical_path_to_net> TNM = "<any_name>";<br> TIMESPEC "TS<another_name>" = PERIOD "<any_name>" <period_length>; I'd recommend going to http://support.xilinx.com, clicking on Software Manuals on the right-hand side,<br>and looking in the Constraints Guide for "PERIOD," "NET," and "TNM." Regards,<br> Hobson
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