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
The major caution to using PLL generated clocks is to watch the clock jitter,
which can be significant at 200MHz. This can be accounted for in the FPGA design
by subtracting the max jitter from the period constraint. It is a bit more
problematic if it is used to clock an ADC or DAC, as then you introduce aperature
jitter which in turn translates to a degradation of the SNR.
rickman wrote:
> Cypress makes several chips that will output a 200 MHz clock using a PLL
> based on a clock at any standard low speed. You can use a 10 MHz
> crystal and generate several clocks of different frequencies using a
> CY22393, for example. The frequency can be programmed in the one time
> EPROM and can be changed (in volatile memory) after power up via a two
> wire serial interface (I2C).
>
> I am using two of these on my board to generate several different clocks
> from one crystal.
>
> "Sławomir Balon" wrote:
> >
> > Hi!
> > I'm looking for fast clock source (200MHz) for epm7032b, it will produce
> > four phase shifted by 90 degree 50MHz clocks. What oscilator should i use?
> > Crystal oscilators offer ends at 120MHz, i didn't ever use any plls at that
> > high freq's. I'm open for any ideas...
> > BTW how they make lets say: 1GSPS in oscilloscopes (i know that on
> > repetitions but how they get those phase shifts for ADCs? - ECL??)
> >
> > thanx
> > Slawek
>
> --
>
> 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
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 41401
Use a local clock that is faster than the I2C SCLK, and then sample both the
SDAT and the SCLK, then find your edges synchronously. By doing this, you
can easily move your effective sampling point on SDAT, and you can easily
filter the clock to eliminate noise problems associated with the slow
edges. Likewise, you have considerably more flexibility in choosing the
relationship of output SDAT with respect to SCLK.
As for hysteresis, the Spartan pins do not have it built in, but you can
easily create an input with hsyteresis by using a second pin as a feedback
output and a pair of resistors. In this case, I don't think you really need
the hysteresis if you use synchronous detection.
rickman wrote:
> The speed of the clock rising edge vs the falling edge is a red
> herring. The problem with the slow edge is not that noise will cause
> double clocking if you use the rising edge, but that noise will cause
> double clocking PERIOD! Even if you use the falling edge to clock the
> register, any noise during the slow rising edge will still cause a
> falling clock edge and double clock your data.
>
> The only advantage of using the falling edge to clock your data has to
> do with noise generation. The logic that changes states on either edge
> will generate some noise. If that is on a slow edge, it will be more
> likely to double clock. But if you have other things going on in your
> CPLD or FPGA, then you will be making noise at all times and you will
> still be sensitive to the noise on the rising edge.
>
> Your real problem is the slow rising edge, PERIOD. Do something with
> it, like buffering it so it is not slow going into the FPGA and use
> hysteresis in the buffer so it will not be sensitive to the noise.
>
> Do any of the Xilinx Spartan inputs have hysteresis? If so, you won't
> need a buffer.
>
> BTW, stable data on the high phase means you either have to clock data
> on the rising edge with 0 setup time, or you have to clock data on the
> falling edge with 0 hold time. 0 hold time can be accomodated in the
> Xilinx parts with an added internal delay element. At least this was
> true of the XC4000 series. I assume the Spartan parts still have it
> since they are based on the XC4000 chips.
>
> But as Philip observed, it would be hard to change data at any time
> other than following the falling edge which would imply lots of setup
> time on the rising edge. Go figure...
>
> Jaime Andres Aranguren Cardona wrote:
> >
> > Hi,
> >
> > On Xilinx' App Note XAP333 is an design of a I2C Master/Slave
> > peripheral for a uProcessor, which I've used as basis for designing a
> > slave device. They say on pag 12 that everything (the state machine
> > and associated counters and shift registers are clocked on the falling
> > edge of SCL, 'cause on heavy loaded systems the rise time of the SCL
> > line may be very slow and that is dangerous on a clock a signal,
> > 'cause it can generate noise on it.
> >
> > However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they
> > say the data on the SDA line must be stable during the HIGH period of
> > the clock.
> >
> > What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a
> > XCS05XL?
> > Sampling on the falling edge (like Xilinx AppNote does) or sampling on
> > he rising edge (as Philips specification suggests)?
> >
> > Thanks a lot.
> >
> > PS/ I would appreciate your replies also be sent to
> > jaime.aranguren@ieee.org
>
> --
>
> 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
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 41402
The spread sheet is a rough estimate. It doesn't really take into
account the routing complexity other than a low, medium, high overall
number. It is probably geared more toward the push-button flow, so the
power reductions gained by carefully floorplanning the data paths are not
reflected. Also, it requires you to make an assumption as to the average
toggle rates.
XPower uses the actual place and route solution and a set of vectors
provided by you that presumably reflects typical operation. Assuming
your vectors really are typical in terms of causing number of nodes to
toggle, the Xpower estimate should be pretty close. Use the Xpower
estimate over the estimator, it is more accurate.
Andy Dow wrote:
> Hi,
>
> I am working on a design in a Virtex 2. It is a FIR filter and uses
> the emebedded multipliers. I have used the Xpwr batch program on this
> design with a VCD file generated by my testbench running in ModelSim.
> I think I have included all the nets in the design as I have used the
> "vcd add -r /i0/*" which should recurse into the blocks and looking
> at the VCD file it seems OK. The testbench runs test data through the
> filter. XPwr give me an estimated power value for this. I have also
> got hold of the Excel spreadsheet Power Estimator for the V2. I have
> filled this out, maybe not as accurately as possible but should be
> roughly correct, and this gives me a value but it seems to be much
> higher.
>
> As anyone else done a comparison? Know which value to use? Or am I
> just missing the point?
>
> Any help would be gratefully received.
>
> Thanks
>
> Andy Dow
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 41403Also posted to news.aldec.com - aldec.support.activeHDL group Insight from ActiveHDL/Altera users appreciated. Hi My system: ActiveHDL 5.1SP2.0.7 with Quartus 2 1.1 SP2 and Leonardo Altera OEM 2001_1d using VHDL throughout. A simple project instantiates a couple of PLLs using the Quartus 2 megawizard - altclklock functions I can get Quartus 2 to do compile/PAR I can get Leonardo to synthesise and then drive Quartus via the cmdline to P&R I can get ActiveHDL to use Quartus to do 'synthesis and P&R' as one item. I cannot however get ActiveHDL to handle the situation with decent synthesis (Leonardo) and Q2 P&R.... In order to use Leonardo with black boxes, Leonardo requires you to exclude the megawizard wrapper VHDL files and just use your top level and any other unrelated files. ActiveHDL drives Leonardo OK either by ticking exclude from synthesis for the megawizard files or not including the files in the first place. However in order to P&R with Quartus2 the P&R needs to take the EDIF output from Leonardo and have those megawizard wrapper vhdl files in the same project directory or else referneced in the quartus project file or tcl command file. Trouble is, ActiveHDL insists on deleting the implementation directory and recreating it without these additional files even if I manually insert them in implementation directory before hitting the design flow implementation button (ie after synthesis I'd copy them across) It won't let me alter the quartus project file to add the correct paths to the megawizard wrappers in the src directory either. I would have expected (hoped) that ActiveHDL could get round any hassle by taking any files ticked as 'exclude from synthesis' and copy them to the implementation working directory after synthesis is over. Any comments on what if anything I'm doing wrong, or other ways to solve this problem. BTW I can carry out activeHDL based synthesis in Leonardo then go into the implementation project directory and manually copy the extra megawizard VHDL files and then manually invoke Quartus using the .quartus project file in the dir to get P&R OK, but Active-HDL hosted P&R won't work because it will actively refresh the implementation dir and delete the 'extra' files that P&R needs. Paul Baxter Email me if you want a simple example with a couple of files pauljnospambaxter@hotnospammail.com without the nospam PS Another thing to fix in 5.1 is support for Altera libraries. The megawizard uses the line: using altera_mf.altera_mf_components.all; Since there is no altera_mf library by default, this can't be analysed by ActiveHDL. You can either change to using altera.altera_mf_components.all; or compile up an additional altera_mf library. Several other altera libs have also been slightly updated in quartus 2 as well. I have created an updated altera.lib, altera_mf.lib, apex20ke.lib and lpm.lib I should however emphasise that the above problem occurs on a completely fresh install with no changed libraries as well as if I replace a few.Article: 41404
How many bits in your count? WIth careful design and layout, you can get to 160
MHz with up to 14 bits, 16-18 in the faster speed grade. To maximize the speed
you need to register and duplicate the controls to the counter (if any) and
place those registers immediately adjacent to the counter in order to avoid
adding route delay to the carry chain delay. For signals that feed all the bits
(such as a clear), you may have to duplicate the signal so that each copy is
only driving a few bits. You'll need to structurally construct the counter in
order to duplicate any controls.
You can also pipeline the carry or use a prescaler to so that the propagation
delay through the carry chain is segmented into short enough chunks to fit
within the 6ns period. Another alternative is to use a counter with a different
non-carry count sequence such as a ring counter or an LFSR, at least for the
prescaler.
deerlux wrote:
> I want to implement a counter of 160Mhz internal clock.The clock of external
> is 80Mhz and doubled by the DLL of Xilinx SpartanII.After I implemented it I
> found the maxium frenquency reported by ISE4.1 is about 140 MHz.In this
> instance, can I implement 160MHz counter?If no,how can I add constrains to
> my design.Which is more important the constrain before synthesis or after
> synthesis?
> --
> _________________________________________
>
> Deerlux White
>
> ICQ#:147863330
>
> SMS: (Send an SMS message to my ICQ): +2783142147863330
>
> More ways to contact me: http://wwp.icq.com/147863330
>
> _________________________________________
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 41405Hi, Just to be curious, what level of difference in terms of power dissipation can you expect between a smart hand placed design and a brute par -ol 1 ? We did a few experiments on a xcv800, but did not observed strong differences (10-15%) at most (these experiment were not done through xpower, but on a real board). Steven Ray Andraka wrote: > It is probably geared more toward the push-button flow, so the > power reductions gained by carefully floorplanning the data paths are not > reflected. Also, it requires you to make an assumption as to the average > toggle rates.Article: 41406
Hi all, We created a VHDL project involving a 16-point FFT from Xilinx' Core Generator. Everything's fine, but when we launch the simulator for the vfft16v2.vhd file, we get an error stating that the Modelsim Evaluation memory limitation has been reached. It is such a small VHDL module that we find it hard to believe that Modelsim rejects it because of its size. But it's possible... Any thoughts? Thanks. ZackArticle: 41407
That is an excellent suggestion. It would be a simple matter to design a clock detector that ignores all transitions around the rising edge and contantly updates an input register while the clock is high. It then holds the input register following the falling edge detection and updates the shift register. If your clock edge detection circuit takes a few clock cycles, you can delay the input data and only use the oldest copy. Or you can trigger off the rising edge and then delay the edge detect a few clock cycles to be sure you are into stable data. This may sound a bit complex, but it will get the job done very cleanly. Ray Andraka wrote: > > Use a local clock that is faster than the I2C SCLK, and then sample both the > SDAT and the SCLK, then find your edges synchronously. By doing this, you > can easily move your effective sampling point on SDAT, and you can easily > filter the clock to eliminate noise problems associated with the slow > edges. Likewise, you have considerably more flexibility in choosing the > relationship of output SDAT with respect to SCLK. > As for hysteresis, the Spartan pins do not have it built in, but you can > easily create an input with hsyteresis by using a second pin as a feedback > output and a pair of resistors. In this case, I don't think you really need > the hysteresis if you use synchronous detection. > > rickman wrote: > > > The speed of the clock rising edge vs the falling edge is a red > > herring. The problem with the slow edge is not that noise will cause > > double clocking if you use the rising edge, but that noise will cause > > double clocking PERIOD! Even if you use the falling edge to clock the > > register, any noise during the slow rising edge will still cause a > > falling clock edge and double clock your data. > > > > The only advantage of using the falling edge to clock your data has to > > do with noise generation. The logic that changes states on either edge > > will generate some noise. If that is on a slow edge, it will be more > > likely to double clock. But if you have other things going on in your > > CPLD or FPGA, then you will be making noise at all times and you will > > still be sensitive to the noise on the rising edge. > > > > Your real problem is the slow rising edge, PERIOD. Do something with > > it, like buffering it so it is not slow going into the FPGA and use > > hysteresis in the buffer so it will not be sensitive to the noise. > > > > Do any of the Xilinx Spartan inputs have hysteresis? If so, you won't > > need a buffer. > > > > BTW, stable data on the high phase means you either have to clock data > > on the rising edge with 0 setup time, or you have to clock data on the > > falling edge with 0 hold time. 0 hold time can be accomodated in the > > Xilinx parts with an added internal delay element. At least this was > > true of the XC4000 series. I assume the Spartan parts still have it > > since they are based on the XC4000 chips. > > > > But as Philip observed, it would be hard to change data at any time > > other than following the falling edge which would imply lots of setup > > time on the rising edge. Go figure... > > > > Jaime Andres Aranguren Cardona wrote: > > > > > > Hi, > > > > > > On Xilinx' App Note XAP333 is an design of a I2C Master/Slave > > > peripheral for a uProcessor, which I've used as basis for designing a > > > slave device. They say on pag 12 that everything (the state machine > > > and associated counters and shift registers are clocked on the falling > > > edge of SCL, 'cause on heavy loaded systems the rise time of the SCL > > > line may be very slow and that is dangerous on a clock a signal, > > > 'cause it can generate noise on it. > > > > > > However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they > > > say the data on the SDA line must be stable during the HIGH period of > > > the clock. > > > > > > What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a > > > XCS05XL? > > > Sampling on the falling edge (like Xilinx AppNote does) or sampling on > > > he rising edge (as Philips specification suggests)? > > > > > > Thanks a lot. > > > > > > PS/ I would appreciate your replies also be sent to > > > jaime.aranguren@ieee.org > > > > -- > > > > 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 > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 -- 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: 41408
Thank you all very much!!! You are a great help :)) Best Regards, HarrisArticle: 41409
Device: XC95144, industrial temp. grade. At room temp. it operates OK. At -25 deg C and below it sometimes fails to configure. This is rather not the problem of supply, since supply is out of temperature chamber during tests and the scope shows that supply rises correctly (20 ms time, monotonic or almost monotonic). Does anybody has some ideas of what to check? TIA DziadekArticle: 41410
I may need to fit an I2C master interface in a CPLD which will have lots of other stuff. Anyone have an estimate of how large an I2C master interface is? I will only be controlling a pair of CY22393 clock chips. So I won't need any fancy features like clock retiming. I can eliminate using a programmable device address since both chips will likely have the same address anyway. So I will probably output to them on separate pins. Cypress gives no data on their interface. They don't even use the term I2C, they just refer you to "industry-standard signaling in both standard and fast modes." It would appear to me that this is just a shift register with timing and control. Is that about it? Any size estimates? -- 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: 41411
Ray Andraka <ray@andraka.com> wrote in message news:<3C9F3692.E83A9C6B@andraka.com>... > Sounds like the geometry of the 32 RPMs is such that the placer can't find a > suitable placement. This is not uncommon when you have reasonably large RPMs, > or a fairly full device. Try manually placing the RPMs with the floorplanner > and then letting the placer do the rest. And if that doesn't work (which it probably will - it doesn't seem like you should be taxing the device with the utilization numbers shown below), you might try turning off the RPM option when you generate the core. Marc > > "S.H.McBader" wrote: > > > Post-Map Timing Analysis reports that all timing constraints have been > > met, in fact there's only one constraint and that is the clock period. > > Device usage indicates that no resource has been estimated over 100%: > > > > Number of Slices: 6,489 out of 6,912 93% > > Number of Slices containing > > unrelated logic: 0 out of 6,489 0% > > Number of Slice Flip Flops: 10,169 out of 13,824 73% > > Total Number 4 input LUTs: 8,508 out of 13,824 61% > > Number used as LUTs: 8,504 > > Number used as a route-thru: 4 > > Number of bonded IOBs: 21 out of 158 13% > > IOB Flip Flops: 10 > > Number of Block RAMs: 32 out of 72 44% > > Number of GCLKs: 1 out of 4 25% > > Number of GCLKIOBs: 1 out of 4 25% > > Number of DLLs: 1 out of 8 12% > > Number of RPM macros: 32 > > Total equivalent gate count for design: 709,935 > > Additional JTAG gate count for IOBs: 1,056 > > > > And yes, it is the Placer which fails! Implementation never gets as far as > > the routing process.. I get numerous warnings similar to: > > > > WARNING:Place:78 - The SLICE component > > "totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579" > > could not be placed. > > > > Followed by errors similar to: > > > > ERROR:Place:1613 - Design object > > (totboard_totem_chip_neuronsarray_neu122_mul_xil_xier_multxil/N1579) > > could not be placed. > > > > So it's neither a case of timing constraints not being met, nor one of > > excessive usage of SLICEs or any other resources..Article: 41412
I am not familiar with the particular template you are trying to simulate, however I have received that warning in the past when simulating several projects with between ~1000-4000 lines of executable code. The performance of the simulator may be adversely affected but you should still be able to simulate the design.Article: 41413
Depends on the design. If it is a heavily data path design, the placer seems
to do a poorer job. The percentage of power seems also to go up as a function
of clock frequency. Typically 10-25% more power for the unfloorplanned design,
although I've seen as much as 80% more.
Steven Derrien wrote:
> Hi,
>
> Just to be curious, what level of difference in terms of power
> dissipation can you expect between a smart hand placed design and
> a brute par -ol 1 ?
>
> We did a few experiments on a xcv800, but did not observed strong
> differences (10-15%) at most (these experiment were not done through
> xpower, but on a real board).
>
> Steven
>
> Ray Andraka wrote:
>
> > It is probably geared more toward the push-button flow, so the
> > power reductions gained by carefully floorplanning the data paths are not
> > reflected. Also, it requires you to make an assumption as to the average
> > toggle rates.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 41414I'm looking for an FPGA family that doesn't require a separate boot PROM. (I can't afford the board space for the second chip.) Does anyone have any suggestions? Please respond by email as I don't regularly read this forum. Thanks! -ChrisArticle: 41415
Chris, all "SRAM-based" FPGA need a source of configuration,since they loose their configuration every time you shut down Vcc. If you don't like that, use antifuse-based FPGAs from Actel and Quicklogic, which are one-time programmable and non-volatile. Sounds nice, but also has lots of problems. If you want to stay with SRAM-based FPGAs, and you have a microprocessor in your system - and most designs do - it can be the source of the configuration bitstream. Many designs do that. Peter Alfke, Xilinx Applications Chris Wilkson wrote: > I'm looking for an FPGA family that doesn't require a separate boot > PROM. (I can't afford the board space for the second chip.) > > Does anyone have any suggestions? > Please respond by email as I don't regularly read this forum. > > Thanks! > -ChrisArticle: 41416
rickman wrote: > > I may need to fit an I2C master interface in a CPLD which will have lots > of other stuff. Anyone have an estimate of how large an I2C master > interface is? > > I will only be controlling a pair of CY22393 clock chips. So I won't > need any fancy features like clock retiming. I can eliminate using a > programmable device address since both chips will likely have the same > address anyway. So I will probably output to them on separate pins. > Cypress gives no data on their interface. They don't even use the term > I2C, they just refer you to "industry-standard signaling in both > standard and fast modes." > > It would appear to me that this is just a shift register with timing and > control. Is that about it? > > Any size estimates? Look at the Philips uC families, for full and partial i2c HW details. If the slaves never have to hold the clock, then you can do i2c entirely in SW, in which case the PLD is just doing PIN-Access. Next level up, would be to have the PLD generate on request single-bit versions of Start/Stop/DataRW. That would appx treble the bandwidth. Maybe half a dozen macrocells. Next up, you could make the BYTE transport automatic, but keep the start/stop/ack manual. We have done this, using a SPI port as fast i2c master. Add appx 10 macrocells. -jg -- ======= 80x51 Tools & IP Specialists ========= = http://www.DesignTools.co.nzArticle: 41417
hamish@cloud.net.au wrote in message news:<3ca06a20$0$11450$afc38c87@news.optusnet.com.au>...
>
> Your code says that you want a flip-flop which is used as an output enable
> for your pins. XST has given you a registered output enable for your pins.
> The output from the synthesis tool is logically correct and matches
> simulation behaviour. You are doing something unusual and in this case
> you must specifically ask for it ie by using synthesis primitives.
>
The discussion seems to be going nowhere, but here is the code
snippet of where I am having the problem.
_______________________________________________________________
inout[31:0] ad;
reg ad_OE_n;
reg[31:0] ad_Port;
assign ad[31:0] = ad_OE_n ? 32'hzzzzzzzz : ad_Port[31:0];
_______________________________________________________________
Again, I am intentionally using only one FF for Output Enable.
I will normally think any synthesis tool should notice that I am not
obeying the IOB packing rules for an OE FF, therefore it should not go
ahead and duplicate the OE FF 32 times even if I am asking IOB FFs to
be merged inside IOBs.
What the tool should do is to duplicate and pack the FFs that's
obeying the IOB packing rules to some extent, and in this case,
ad_Port[31:0] should be duplicated and packed into IOBs.
Otherwise, I believe the designer will totally lose control of the
design, and I will like to see synthesis tool vendors to understand
that.
The workaround I found recently which I consider it near
perfect is to put two dummy inverters in front of ad_OE_n.
_______________________________________________________________
inout[31:0] ad;
reg ad_OE_n;
reg[31:0] ad_Port;
wire ad_OE_n_Inverted_Once;
wire ad_OE_n_Inverted_Twice;
assign ad_OE_n_Inverted_Once = !(ad_OE_n);
assign ad_OE_n_Inverted_Twice = !(ad_OE_n_Inverted_Once);
assign ad[31:0] = ad_OE_n_Inverted_Twice ? 32'hzzzzzzzz :
ad_Port[31:0];
_______________________________________________________________
Of course, putting the inverters alone won't do the job
considering that the synthesis tool will probably notice that I am
inverting something twice, and remove it because that's normally
useless.
I will have to use "keep" synthesis attribute to prevent
ad_OE_n_Inverted_Once and ad_OE_n_Inverted_Twice from disappearing.
_______________________________________________________________
inout[31:0] ad;
reg ad_OE_n;
reg[31:0] ad_Port;
// synthesis attribute keep of ad_OE_n_Inverted_Once : signal is
"true"
wire ad_OE_n_Inverted_Once;
// synthesis attribute keep of ad_OE_n_Inverted_Twice : signal is
"true"
wire ad_OE_n_Inverted_Twice;
assign ad_OE_n_Inverted_Once = !(ad_OE_n);
assign ad_OE_n_Inverted_Twice = !(ad_OE_n_Inverted_Once);
assign ad[31:0] = ad_OE_n_Inverted_Twice ? 32'hzzzzzzzz :
ad_Port[31:0];
_______________________________________________________________
The keep attribute will prevent XST from optimizing the inverters away
(Yes, I am aware the inverters are built out of 4-input LUTs.), and
this breaks the IOB FF packing rules nicely.
The reason I call this solution "near perfect," of course, is because
I feel like I really shouldn't have to put two inverters in front of
the OE FF, but since most tools don't seem to respect the designer's
original intention, this method seems to be the only way to work
around the issue.
With this IOB OE FF issue virtually solved, I can now get my
synthesizable PCI IP core to meet 33MHz PCI's Tsu < 7ns with only
automatic P&R and the lowest routing effort in Spartan-II-5.
That's unimaginable a few months ago when I was struggling to meet Tsu
< 7ns.
> I think you would be very disappointed with the synthesis results if
> the tool didn't do little things like this. For example, state machine
> encoding; the tools usually default to one-hot or auto-detect but
> the most obvious code probably implies a binary encoding. Similarly,
> no register duplication or buffering which would give significantly
> worse timing results in some designs. You also depend on the tool
> for automatic IBUF/OBUF/IOBUF instantiation which saves a lot of
> time and a lot of messy code.
>
I use one-hot encoding in my PCI IP core considering that to
meet Tsu, I need to have as fewer levels of LUTs as possible, and
since one-hot encoding uses only one FF to signal a state, that helps
to keep the levels of LUTs low.
But I do still let the synthesis tool choose the encoding, and XST
always seems to choose one-hot.
Yes, I do appreciate most synthesis optimizations, and I
especially appreciate output FF register duplication because without
that, most of my output FFs won't be able to get merged into IOBs, and
not make Tco (Tval) < 11ns requirement of 5V 33MHz PCI.
> There is no way that the tool can please everyone. It can either
> be dumb by default (which will suit you in this case but not
> many other people) or smart. There will always be times when
> you have to disable the smart behaviour. As long as that is
> easy, the smart behaviour is the correct default.
>
> My only complaint would be that it's often too difficult to
> disable these optimisations.
>
> Hamish
No, I am not asking XST to be dumb at all.
When Pack I/O Registers into IOBs option is turned on, I still want it
to notice that it needs to duplicate output FFs, but it shouldn't go
ahead and duplicate an OE FF 32 times when my design clearly doesn't
do so.
Page 5-69 (Page 279 of 480) of Synthesis and Simulation Design Guide I
downloaded from Xilinx says, "All FFs that are to be pulled
into the IOB must have a fanout of 1. This applies to output and
tristate enable registers. For example, if there is a 32 bit
bidirectional bus, then the tristate enable signal must be replicated
in the original design so that it will have a fanout of 1."
http://toolbox.xilinx.com/docsan/xilinx4/pdf/docs/sim/sim.pdf
My interpretation of the above condition is that it is the designer's
responsibility to duplicate OE FFs in its design, and the designer
shouldn't expect the synthesis tool to automatically duplicate the OE
FFs for you.
But I already made this issue a non-issue by putting dummy inverters
(LUTs) with keep attribute in front of them to prevent XST from
getting rid of the inverters, so I guess I am sort of happy with the
solution I found, although it took me about 2 weeks to figure out that
solution.
I do agree with you that it is often very hard to overcome
synthesis tool's unwanted optimizations, and that's the reason why it
took me 2 weeks to figure out a workaround solution
. (Although I wasn't dealing with that issue the all the time.)
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41424Dziadek wrote: > Device: XC95144, industrial temp. grade. > At room temp. it operates OK. > At -25 deg C and below it sometimes fails to configure. > This is rather not the problem of supply, since supply is out of temperature > chamber during tests and the scope shows that supply rises correctly (20 ms > time, monotonic or almost monotonic). Are you trying to erase and write a new configuration to the CPLD in the cold chamber? Is it necessary for this to work? Is it OK to configure the CPLD at room temp, and then run the CPLD at other temps? Or, am I misunderstanding the word "configure"? Jon
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