Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 36325

Article: 36325
Subject: Re: Registered as well as unregistered outputs?
From: digari@dacafe.com (digari)
Date: 6 Nov 2001 05:05:25 -0800
Links: << >>  << T >>  << A >>
Talking about more practical situation, the registered and the
unregisted output of a LE can be used in the State Machine
implementations

Ray Andraka <ray@andraka.com> wrote in message news:<3BE6AE22.5AFA3717@andraka.com>...
> It simply gives synthesis and mapping more options.  Often, synthesis will share the
> combinatorial logic in front of a flip-flop, necessitating an unregistered connection.
> With the 10K architecture, any shared logic prevents the use of the flip-flop.
> 
> nitin wrote:
> 
> > Hi...
> >
> >     Well i was very much asking from the veiw point of FLEX10K and
> > APEX20K architectures. U see in 10K they had one output of the LE
> > going to the feedback matrix of the LLI and one output to RFTs and
> > CFTs. So that meant only either registered or unregistered output
> > going to the LLI feedback matrix and also to the RFT's and CFTs.
> >
> >     But that changed with APEX20K devices where both outputs could got
> > to all routing resources. Now is that becuse they wanted both
> > registered and unregisterd outputs at the same time...?  What was the
> > need that made them to do this change in the architecture...? I
> > presumed there might be circuits where one might need that.
> >
> >     Well some more discussion on this will help a lot.
> >
> > Nitin.
> >
> > Ray Andraka <ray@andraka.com> wrote in message news:<3BE298CA.B67829D6@andraka.com>...
> > > Depends entirely on your design style.  For highest performance, you'll
> > > generally want to avoid using the unregistered output, but that also
> > > limits your design options.
> > >
> > > nitin wrote:
> > >
> > > > Hi...
> > > >
> > > > Can anyone tell me how frequently and where both registered and
> > > > unregistered outputs from an LE are required...?
> > > >
> > > > Ciao,
> > > > nitin.
> > >
> > > --
> > > --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
> 
> --
> --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: 36326
Subject: Virtex2 gate-level simulation: SDF and timing errors
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 6 Nov 2001 06:42:09 -0800
Links: << >>  << T >>  << A >>
Hi everyone,

I am trying to simulate the gate-level VHDL file generated by Xilinx
P&R tools. My test design is a bunch of counters connected to an 
inferred distributed-RAM. The target device is a Virtex-2 chip.

When I simulate the gate-level VHDL by itself, I get timing violation 
warnings (sometimes) when writing to the distributed-RAM; watching the
simulator waveforms, it appears that the clock to the RAM has a 100-pS
phase difference to the counters' clock (the clock is routed as a 
global clock net).

When I add the gate-level SDF file to the simulation, all the timing
violation warnings disappear (for all cases: min, max and typ).

Trying to trace the generated VHDL code, I see that signals are routed
through buffer entities, with built-in delays; apparently the VHDL
design itself contains all required delays.

Why would adding the SDF to the simulation make errors _disappear_? 
it should be a more thorogh timing-check and find _more_ timing
errors.

Can anyone explain?

    Thanks in Advance
    Assaf Sarfati

Article: 36327
Subject: Re: Counter detects both edge of clock?? (verilog)
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Tue, 6 Nov 2001 10:42:48 -0500
Links: << >>  << T >>  << A >>
How critical is the timing ? You could use a frequency doubler which
generates a glitch pulse on each clock edge and count that.

Rob
htttp://www.birdcomputer.ca/

"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3BE7B477.AD2BA09D@algor.co.uk...
>
>
> dfx2001 wrote:
>
> > who knows how to detect both edges (rising and falling edge) of clock in
> > verilog?
> >
> > always @(posedge clk or negedge clk)
> > counter <= counter + 1; //only count 1, not 2
> >
> > Thanks.
>
> An ``always'' block is triggered when any thing in the sensitivity list
> changes - the bit between the `(' and `)'. So you need:
>
> always @(clk)
>   ....
>
> If you try to synthesise this you will get a latch & not the FFs you
> probably want.
>
>
>



Article: 36328
Subject: Re: Counter detects both edge of clock?? (verilog)
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 06 Nov 2001 10:11:07 -0800
Links: << >>  << T >>  << A >>
"dfx2001" <dfx2001@263.net> writes:
> who knows how to detect both edges (rising and falling edge) of clock in
> verilog?
> 
> always @(posedge clk or negedge clk)
> counter <= counter + 1; //only count 1, not 2

I don't know verilog, but in VHDL it's certainly easy to write
code that is triggered on both edges.  The problem is that it generally
can't be synthesized, because there aren't flip-flops that clock
on both edges.  There are kludgey ways to make it work, but it's best
to reformulate the problem so it doesn't require clocking on both
edges.

One approach to what you want is to have two counters, clocked on
opposite edges, and add the outputs.

But if one thinks about the problem a bit, a simpler solution becomes
apparent.  If you just count the falling transitions, you will get
half the count you want, but without being able to distinguish whether
there has been a rising transition.  If there has not been a rising
transition, the low bit of your desired count is zero.  If there has,
the low bit will be one.  Thus the value of the input is itself equal
to the least significant bit of your desired count.

For an n-bit count output, you simple use an n-1 bit counter triggered
on the falling edge of the clock:


                                         clock
                                         input
                                           |
      +--------------------------------+   |
      | (n-1) bit        __            |   |
      |  counter           \__  clock <|---+
      |                                |   |
      |  Q [n-2]     ...   Q  [0]      |   |
      +--------------------------------+   |
            |                |             |
            V                V             V
       count [n-1]   ...  count [1]     count [0]

Article: 36329
Subject: Re: Xilinx DLL clock question
From: Ray Andraka <ray@andraka.com>
Date: Tue, 06 Nov 2001 18:20:36 GMT
Links: << >>  << T >>  << A >>
In theory yes, but if you have any jitter on the clocks, you may have problems.
Note that you can get substantial clock jitter due to switching I/Os on the same
bank as the clock input, so even with a very stable external clock you can have
problems.  Also, widely different loading on the clock networks can induce a
sizable skew between the clocks.  A safer tact would be careful use of clock
enables to make sure transitions happen away from the edges where they are
clocked into the opposite domain.  (We were bitten by this when the Virtex parts
first came out, so we take care to make safe crossings in our designs now).

Dan Kuechle wrote:

> If I use two DLL's to generate a x4 clock such that the rising edges of the
> x1 and x4 clocks align, and have the x1 and x4 clks on global clocks
> buffers, can I go from one clock domain to the other with just a flip flop?
> In other words, are the rising edges aligned close enough so I don't have to
> worry about metastability and other nasty things?
>
> Dan

--
--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: 36330
Subject: Re: speed of adder in XC1000E-6
From: Ray Andraka <ray@andraka.com>
Date: Tue, 06 Nov 2001 18:27:57 GMT
Links: << >>  << T >>  << A >>


khtsoi@cse.cuhk.edu.hk wrote:

> Ray Andraka <ray@andraka.com> wrote:
> > You are apparently traversing two chains in this particular path.  The
> > data sheet performance is based on a single carry chain, which you'll see
> That's the real problem. I just don't know how to tell the tools not to
> break the chain (Synopsys Design Compiler & Xilinx Alliance 3.1i).
> Must I use core gen?

The tools shouldn't be breaking the chain, although at 64 bits, it may have to
be broken to fit within the height of your device.  For 64 bits, the array has
to be at least 32 CLBs tall to avoid breaking the chain.

>
>
> > as the Topcyf or g to get on, + N-2 * Tbyp for each bit pair in the
> > chain, plus a Tciny or Tcisu for the time to get off the chain.  To
> > achieve the data sheet performance, you'll need to use the clb registers
> > on the output in the same slice as the carry chain, AND you'll have to
> > register all the inputs in an adjacent slice with no other loads on the
> > registered inputs.
> Is that mean I cannot drive other devices by the adder outputs directly?
> Then how can I implement i+j+k in one clock cycle?

You can do that by cascading adders, but be aware that you will not reach the
data sheet performance.  That is two layers of adders.  I think you'll improve
your timing a little by using a carry save layer to reduce the 3 input vectors
to a carry vector and a sum vector, then adding those together in a
conventional adder (a shallow wallace tree).  It will still not hit the data
sheet performance, but you'll at least reduce the delay to the adder plus a LUT
in front of it.

>
>
> Anyway, thanks a lot!
>
> ---- Brittle

--
--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: 36331
Subject: Re: RLOC for a block
From: Ray Andraka <ray@andraka.com>
Date: Tue, 06 Nov 2001 18:32:20 GMT
Links: << >>  << T >>  << A >>
The macros do not have edif netlists, therefore you either have to produce your
own, or figure out how to generate a netlist for the macro.  Use Coregen instead,
as that produces placed edif netlists.

RLOCs are hierarchical.  As long as the lowest level has RLOC'd primitives, then
you can put RLOCs on your design components.  They work the same way as with the
primitives.  Refer to the XIlinx libraries guide for the details.

khtsoi@cse.cuhk.edu.hk wrote:

> khtsoi@cse.cuhk.edu.hk wrote:
> > Hi,
>
> > I have just learnt to use RLOC to place the components closer inside a larger
> > component. But how can I forece these larger components to be closer by RLOC.
> > I mean, the component created by myself will not have RLOC attribute and/or
> > other attributes like the LUT4, FDC, etc. Neigther of them will be a regular
> > block (e.g. not a rectangular box). How to instruct the par tools to place
> > them in certain, fixed place? (Using VHDL only!) Thanks in advance!
>
> > ---- Brittle
> Actually I want to use the ADD8 macro in VirtexE. But the gndbuild tool always
> report error not finding the ADD8 component. It can find something like LUT4
> but no macro can be used. I search the alliance3.1i directory and cannot find
> any NMC file. How to use the macro like ADD8 or must I write it by myself?
>
> ---- Brittle

--
--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: 36332
Subject: placement for if (vhdl)
From: Jens-Christian Lache <lache@tuhhN0ZPAM.de>
Date: Tue, 06 Nov 2001 21:40:31 +0100
Links: << >>  << T >>  << A >>
Dear newsgroup!

I have a question concerning a placement constraint.
If I have the following process:

myProc: process(clock,reset)
type statemachineType (one,two);
variable statemachine statemachineType;
begin
    if (reset = '1') then
        statemachine := one;
        something <= '0';
    elsif (rising_edge(clock)) then
        case statemachine is
            when one =>
                something <= '0';
                if (signal1 = '1' and signal2 = '0' and signal3 = '1')
then
                    statemachine := two;
                end if;
            when two =>
                    something <= '1';
            when others => null;
         end case;
    end if;
end process;

the if statement will result in a LUT4. I can set placement
constraints for the statemachine variable FFs, but how can I fixate
the location of the lookup table?

I tried to handwire a LUT outside of the process like

myLUT: LUT3 port map (
            I0 => signal1,
            I1 => signal2,
            I3 => signal3,
            O => switchState);

and then in the process:

if (switchState = '1') then
    statemachine := two;
end if;

This allows to place the LUT, but introduces a new logic stage and
is therefor useless.

Any ideas?

Thanks,

-jc-


Article: 36333
Subject: Re: Xilinx Floorplanner Effectiveness
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Tue, 06 Nov 2001 21:23:49 GMT
Links: << >>  << T >>  << A >>
If you are using the Insight (Xilinx) PCI core, it should come with all the
UCF files (and perhaps guide files) that include the proper placement to
meet timing.  Also, if you purchased the PCI core from Insight, that may
include several hours of support from Insight Design Services, who are the
PCI experts.

"Kevin Brace" <kevinbraceusenet@hotmail.com> wrote in message
news:cc7b0b5f.0111042343.3cade106@posting.google.com...
> I will like to know effective is the Floorplanner software that comes
> with Xilinx ISE series of software.
> The design I am working on is a PCI IP core which Tsu (setup time) has
> to be less than 7ns, and Tval (clock to output valid) has to be less
> than 11ns.
> Currently, the worst Tsu I have is 12.974ns, and the worst Tval I have
> is 16.594ns.
> I synthesized my design with XST Verilog, and I used only automatic
> P&R with user constraints (Pad to Setup = 7ns, Clock to Pad = 11ns).
> The software I am currently using is ISE WebPack 4.1.
> Is it realistic to expect that I will get Tsu and Tval within 7ns and
> 11ns respectively if I use the Floorplanner?
> Will reducing fan-out during synthesis help?
> If so, what number (default is 100) is appropriate?
> Are there any other helpful synthesis/P&R options that will improve
> the timings?
> The part I am using is Spartan-II 150K system gate part speed grade -5
> which comes with Insight Electronics Spartan-II PCI Development Kit,
> so the use of speed grade -6 is not an option.
> I already synthesized my design with the speed grade -6, and that
> improved the worst timings by 20%, but that still wasn't enough by
> about 15%.
> I already tried "Pack I/O Registers/Latches into IOBs" in MAP.
> If I packed IOBs for input by selecting "For Inputs Only" or "For
> Inputs or Outputs", it created a positive hold time, a no-no in PCI
> (hold time has to be 0ns in PCI).
> Selecting "For Outputs Only" didn't seem to improve Tval that much.
> If the Floorplanner is going to help, what kinds of strategies should
> I use to hand place the design?
>
>
>
> Regards,
>
>
>
> Kevin Brace (don't respond to me directly, respond within the
> newsgroup)



Article: 36334
Subject: Re: placement for if (vhdl)
From: Ray Andraka <ray@andraka.com>
Date: Tue, 06 Nov 2001 21:48:04 GMT
Links: << >>  << T >>  << A >>
The logic (the if statement) has to be encoded into the INIT attribute of
the LUT, and then the process reduces to just the flip-flop.  If you
instantiate the LUT and the Flip-flop the placement constraints can be put
on them right in the VHDL as RLOCs.  Encoding the LUT is awkward, as you
might have guessed, especially if you are starting out with a text
construct like the if-then-else.

If you can keep the combinatorial logic to a single layer, then the mapper
will place that logic with the flip-flop, and you avoid having to place
the LUTs.  If the LUT drives the reset or set of and FDR or FDS, or drives
the clock enable, or drives another LUT, then you'll end up with a LUT
that doesn't place with the flip-flop.  Unfortunately the placer seems to
do an exceptionally poor job at placing second level LUTs like that.

If you are using synplicity, you can put your lut logic inside a separate
component and put the xc_map attribute on it.  That permits you to place
the LUT as well.  In that case, you can put the if-then-else logic inside
the separate component.

I try to avoid having to place the LUTs since it is awkward and gives
fairly hard to read code.  It is often necessary however.



Jens-Christian Lache wrote:

> Dear newsgroup!
>
> I have a question concerning a placement constraint.
> If I have the following process:
>
> myProc: process(clock,reset)
> type statemachineType (one,two);
> variable statemachine statemachineType;
> begin
>     if (reset = '1') then
>         statemachine := one;
>         something <= '0';
>     elsif (rising_edge(clock)) then
>         case statemachine is
>             when one =>
>                 something <= '0';
>                 if (signal1 = '1' and signal2 = '0' and signal3 = '1')
> then
>                     statemachine := two;
>                 end if;
>             when two =>
>                     something <= '1';
>             when others => null;
>          end case;
>     end if;
> end process;
>
> the if statement will result in a LUT4. I can set placement
> constraints for the statemachine variable FFs, but how can I fixate
> the location of the lookup table?
>
> I tried to handwire a LUT outside of the process like
>
> myLUT: LUT3 port map (
>             I0 => signal1,
>             I1 => signal2,
>             I3 => signal3,
>             O => switchState);
>
> and then in the process:
>
> if (switchState = '1') then
>     statemachine := two;
> end if;
>
> This allows to place the LUT, but introduces a new logic stage and
> is therefor useless.
>
> Any ideas?
>
> Thanks,
>
> -jc-

--
--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: 36335
Subject: Re: How can I use the instance of block RAM of Spartan2 in Synplify?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 06 Nov 2001 23:37:19 +0000
Links: << >>  << T >>  << A >>


duola wrote:

> I want use RAM in my Spartan2 chip.When I use the instance of block RAM of
> Spartan2 as following:
>
> module ram(clk,we,din,dout,addr);
> input clk,we;
> input [7:0]din;
> input [8:0]addr;
> output [7:0]dout;
> RAMB4_S8
> ram0(.WE(we),.EN(1'b0),.RST(1'b0),.WE(we),.ADDR(addr),.DI(din),.DO(dout));
> endmodule
>
> But synplify gave me an error"Reference to undefined module RAMB4_S8".Does
> Synplify support the Spartan2 family?Why does it not recognize the block RAM
> of Spartan2?
> Who can tell me?
> Thank you!
> Deerlux White

You need to add the Synplify ``Black Box'' stub library to the list of Verilog
source files when synthesising. You should find it in:

<Synplify_Install_Dir>/synplify/lib/xilinx/<device_family>.v

For Spartan2 device_family = virtex.




Article: 36336
Subject: Re: Altera download problem
From: leon_heller@hotmail.com (Leon Heller)
Date: 6 Nov 2001 16:14:36 -0800
Links: << >>  << T >>  << A >>
Someone from Altera got back to me the other day, having seen my
original posting. They will be reorganising their download facility,
which should resolve the problem.

Leon

Article: 36337
Subject: Re: Xilinx Floorplanner Effectiveness
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 6 Nov 2001 16:59:42 -0800
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3BE79170.48636C95@algor.co.uk>...
> Ray Andraka wrote:
> 
> > The floorplanner won't help with I/O timing if you have the I/Os
> > registered in the IOB.  You should, however check to verify that the
> > registers did go into all the IOBs on your critical path.  There are a
> > number of conditions that have to be met for the register to go into the
> > IOB; miss one of them, and the register goes into the core getting you a
> > longer input setup and output clk to Q.  Set the output ffs to a faster
> > slew rate, and set the input ones to no delay.  Use the DLL to keep the
> > internal clock phase aligned with your external clock (that'll reduce the
> > times).  7 and 11 should be OK with registered I/O in a spartanII-5.  You
> > probably won't reach those numbers if you don't use the register in the
> > I/O
> >
> > Kevin Brace wrote:
> >
> >
> 
> All Ray's suggestions are correct 'cept the DLL one. Whether or not you can
> use this on the PCI clock  depends on whether you are going to follow the PCI
> spec strictly and allow the clock min frequency to be 0.  Even if your
> architecture doesn't do PCI clock stopping the DLL imposes a min freq. limit
> (25MHz for V-E ?).

        After reading Ray's advise, I tried to attach a DLL macro (the
standard DLL macro inside Xilinx Application Note 174 zip file) to the
clk input of the PCI IP core, but I couldn't get past MAP (got
errors).
But I forgot that in PCI, the clock frequency can be at any frequency
between 0 through 33MHz (in 33MHz PCI), and the application note also
mentioned that it is not recommended to change the clock frequency
when the DLL is being used, so I guess I won't be able to use the DLL.
        I am personally going to follow the specification strictly,
even though I know it seems stupid to do so, since even Intel doesn't
follow the specification.
For example, recent Intel chipsets don't support data parity error
checking (they don't have PERR# signal).
Because I am following the specification strictly, I bothered to
implement data parity error checking during target access, which in
practice no one uses or cares.



> 
> PCI timing posed a real problem for the PCI i/f I did ~3 years ago in an
> XCV300-4. Tco was not a problem once I'd persuaded Synplify not to mess up
> the IOB packing rules. Tsu was a whole other story since the PCI protocols
> make it  very difficult to use registered inputs. With a lot of sweat I
> managed to get Tsu down to ~7.5-8 nsec with the automatic tools. Ray will
> remember that this was in the early Virtex days when Xilinx's attitude was
> ``FloorPlanner? Virtex doesn't need it''.


        When I set "Pack I/O Registers/Latches into IOBs", to  
"For Inputs Only" or "For Inputs and Outputs", it introduces hold time
on the inputs, which has to be 0ns in PCI.
Setting "Pack I/O Registers/Latches into IOBs", to "For Outputs Only"
or "For Inputs and Outputs", didn't seem to improve Tval (Tco) timings
that much.
Perhaps it is because of clock skew in my design, but can it also be
because I put a multiplexer before a tri-state buffer?


                            /
goes into                  {----------------------
PCI Target Sequencer and    \                    |
Backend Bus                                      |
                                                 |
                                                 |
                                                 |
TRDY_n Select ----------------------------       |
                                         |       |
                                        \|/      |
                                   ------------  |
                                  \|          |  |
from PCI Target Sequencer TRDY_n --|          |  |
                (D-FF)            /|          |  | \
                                   |    MUX   |----- to Tri-State
Buffer
                                  \|          |    /
from Backend Bus TRDY_n -----------|          |
                (D-FF)            /|          |
                                   ------------




TRDY_n OE -----------------------
                                |
                                |
                              \ |
                             | \|/
                             |  \
                            \|   \                  \
from MUX --------------------|Tri/------------------- to TRDY_n pin
                            /|  /                   /
                             | /
                             |/


Although the diagram says the diagram is for TRDY_n, things are also
identical for DEVSEL# and STOP#, and output section of AD[31:0]
(AD[31:0] is bidirectional, but input part of it is not shown here).
In my design, initially (first three clock cycles), PCI Target
Sequencer drives AD[31:0], DEVSEL#, TRDY#, and STOP#.
However, after the Backend Bus is ready (from fourth clock cycle), the
Backend Bus drives AD[31:0], DEVSEL#, TRDY#, and STOP#, until the end
of the transaction.
Because I have a requirement that Backend Bus has to take over the
control of the PCI bus, I don't see how I can get rid of the
multiplexer.
Perhaps, if I somehow got rid of the requirement of letting the
Backend Bus control the PCI bus, I can get rid of the multiplexer,
then I will only have a D-FF coming from PCI Target Sequencer into a
tri-state buffer.
My guess is that that's the only situation in which the D-FF can be
included inside the IOB.


> 
> On top of this the device had to live in a system where the clock was stepped
> up from 8, 24, 32MHz and used spread spectrum EMI reduction.
> 
> I was fortunate in that we were working in a ``closed'' PCI universe with a
> limited range of other PCI masters and a short bus so the 1nsec error didn't
> matter.
> 
> I've since figured out a way to use registered inputs (I think) but with
> Virtex-E -6 I don't yet need it for 33MHz PCI.


        The only problem I can think of Virtex-E is that it doesn't
support 5V tolerent I/O, so without an external resistor or a logic
level conversion chip (It seems like recent nVidia and ATi PCI
graphics cards put that between the chip and PCI) I cannot plug such a
card into a 5V PCI slot.
        In my case setting "Pack I/O Registers/Latches into IOBs", to
"For Inputs Only" or "For Inputs and Outputs" introduce hold time on
the inputs, which has to be 0ns in PCI.
How were you able to avoid having any hold time?
I guess the way I designed my PCI IP core causes the problem.
Just for reference, here is the result I got for Post-P&R report,
followed by P&R report.
One thing I am starting to notice is that, most inputs with Logic
Levels of 4 or less seem to meet Tsu = 7ns, but if it goes to Logic
Levels of 5 or above, it starts to miss Tsu timings.
It seems like (I guess it is sort of common sense) Logic Levels have
direct impact on Tsu.
        Another interesting thing I noticed just yesterday is for Map
Properties -> Optimization Strategy, if I select Speed, it gives
result far worst for Tsu (not much change in Tco) than Balanced, Area,
or Off.

Speed:       Timing errors: 292  Score: 299067
Balanced:    Timing errors: 87  Score: 157911
Area or Off: Timing errors: 127  Score: 162399



I am surprised to see that P&R score differs so much by just one
option selection I make.
I am afraid that the worst Tsu number I mentioned in the initial
posting (worst Tsu = 12.974ns) may have been because I set Map
Properties -> Optimization Strategy to Speed thinking that will give
the best result.
I guess being too aggressive doesn't always pay off.



Regards,



Kevin Brace (don't respond to me directly, respond within the
newsgroup)




***********************************************************************
54 constraints not met.


Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)

Setup/Hold to clock CLK
---------------+------------+------------+
               |  Setup to  |  Hold to   |
Source Pad     | CLK (edge) | CLK (edge) |
---------------+------------+------------+
AD<0>          |    7.886(R)|    0.000(R)|
AD<10>         |    7.312(R)|    0.000(R)|
AD<11>         |    4.227(R)|    0.000(R)|
AD<12>         |    5.628(R)|    0.000(R)|
AD<13>         |    6.380(R)|    0.000(R)|
AD<14>         |    5.961(R)|    0.000(R)|
AD<15>         |    6.280(R)|    0.000(R)|
AD<16>         |    7.249(R)|    0.000(R)|
AD<17>         |    7.098(R)|    0.000(R)|
AD<18>         |    7.119(R)|    0.000(R)|
AD<19>         |    7.122(R)|    0.000(R)|
AD<1>          |    7.999(R)|    0.000(R)|
AD<20>         |    7.022(R)|    0.000(R)|
AD<21>         |    6.979(R)|    0.000(R)|
AD<22>         |    6.675(R)|    0.000(R)|
AD<23>         |    6.775(R)|    0.000(R)|
AD<24>         |    7.061(R)|    0.000(R)|
AD<25>         |    6.621(R)|    0.000(R)|
AD<26>         |    6.879(R)|    0.000(R)|
AD<27>         |    6.870(R)|    0.000(R)|
AD<28>         |    6.633(R)|    0.000(R)|
AD<29>         |    6.708(R)|    0.000(R)|
AD<2>          |    5.982(R)|    0.000(R)|
AD<30>         |    7.127(R)|    0.000(R)|
AD<31>         |    7.067(R)|    0.000(R)|
AD<3>          |    4.989(R)|    0.000(R)|
AD<4>          |    4.718(R)|    0.000(R)|
AD<5>          |    5.181(R)|    0.000(R)|
AD<6>          |    6.666(R)|    0.000(R)|
AD<7>          |    5.465(R)|    0.000(R)|
AD<8>          |    7.408(R)|    0.000(R)|
AD<9>          |    6.578(R)|    0.000(R)|
C_BE_n<0>      |    6.536(R)|    0.000(R)|
C_BE_n<1>      |    6.666(R)|    0.000(R)|
C_BE_n<2>      |    6.964(R)|    0.000(R)|
C_BE_n<3>      |    7.251(R)|    0.000(R)|
FRAME_n        |    7.631(R)|    0.000(R)|
IDSEL          |    7.670(R)|    0.000(R)|
IRDY_n         |    7.671(R)|    0.000(R)|
PAR            |    6.006(R)|    0.000(R)|
RST_n          |    6.486(R)|    0.000(R)|
---------------+------------+------------+

Clock CLK to Pad
---------------+------------+
               | CLK (edge) |
Destination Pad|   to PAD   |
---------------+------------+
AD<0>          |   15.604(R)|
AD<10>         |   15.104(R)|
AD<11>         |   15.066(R)|
AD<12>         |   14.594(R)|
AD<13>         |   14.782(R)|
AD<14>         |   15.215(R)|
AD<15>         |   15.352(R)|
AD<16>         |   15.160(R)|
AD<17>         |   14.660(R)|
AD<18>         |   15.298(R)|
AD<19>         |   13.926(R)|
AD<1>          |   15.880(R)|
AD<20>         |   14.588(R)|
AD<21>         |   14.772(R)|
AD<22>         |   14.639(R)|
AD<23>         |   15.150(R)|
AD<24>         |   15.157(R)|
AD<25>         |   14.837(R)|
AD<26>         |   15.045(R)|
AD<27>         |   14.844(R)|
AD<28>         |   14.831(R)|
AD<29>         |   14.448(R)|
AD<2>          |   15.493(R)|
AD<30>         |   15.320(R)|
AD<31>         |   14.768(R)|
AD<3>          |   15.430(R)|
AD<4>          |   15.176(R)|
AD<5>          |   15.659(R)|
AD<6>          |   15.233(R)|
AD<7>          |   16.103(R)|
AD<8>          |   16.064(R)|
AD<9>          |   15.586(R)|
DEVSEL_n       |   14.705(R)|
PAR            |   12.504(R)|
PERR_n         |   12.828(R)|
SERR_n         |   12.190(R)|
STOP_n         |   14.358(R)|
TRDY_n         |   15.560(R)|
---------------+------------+

Clock to Setup on destination clock CLK
---------------+---------+---------+---------+---------+
               | Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock   |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
CLK            |   14.051|         |         |         |
---------------+---------+---------+---------+---------+


Timing summary:
---------------

Timing errors: 87  Score: 157911

Constraints cover 6946 paths, 0 nets, and 3159 connections (92.7%
coverage)


Analysis completed Tue Nov 06 14:52:01 2001
--------------------------------------------------------------------------------
***********************************************************************



***********************************************************************
WARNING:Par:62 - Timing constraints have not been met.

Asterisk (*) preceding a constraint indicates it was not met.

--------------------------------------------------------------------------------
  Constraint                                | Requested  | Actual    
| Logic
                                            |            |           
| Levels
--------------------------------------------------------------------------------
  TS_CLK = PERIOD TIMEGRP "CLK"  30 nS   HI | 30.000ns   | 14.051ns  
| 5
  GH 50.000000 %                            |            |           
|
--------------------------------------------------------------------------------
  COMP "C_BE_n<0>" OFFSET = IN 7 nS  BEFORE | 7.000ns    | 6.536ns   
| 4
  COMP "CLK"                                |            |           
|
--------------------------------------------------------------------------------
  COMP "C_BE_n<1>" OFFSET = IN 7 nS  BEFORE | 7.000ns    | 6.666ns   
| 4
  COMP "CLK"                                |            |           
|
--------------------------------------------------------------------------------
  COMP "C_BE_n<2>" OFFSET = IN 7 nS  BEFORE | 7.000ns    | 6.964ns   
| 5
  COMP "CLK"                                |            |           
|
--------------------------------------------------------------------------------
* COMP "C_BE_n<3>" OFFSET = IN 7 nS  BEFORE | 7.000ns    | 7.251ns   
| 5
  COMP "CLK"                                |            |           
|
--------------------------------------------------------------------------------
* COMP "FRAME_n" OFFSET = IN 7 nS  BEFORE C | 7.000ns    | 7.631ns   
| 5
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "IDSEL" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 7.670ns   
| 5
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "IRDY_n" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.671ns   
| 5
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
  COMP "RST_n" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 6.486ns   
| 2
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<0>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 7.886ns   
| 5
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<0>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.604ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<10>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.312ns   
| 5
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<10>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.104ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<11>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 4.227ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<11>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.066ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<12>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 5.628ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<12>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.594ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<13>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.380ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<13>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.782ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<14>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 5.961ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<14>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.215ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<15>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.280ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<15>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.352ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<16>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.249ns   
| 6
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<16>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.160ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<17>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.098ns   
| 6
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<17>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.660ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<18>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.119ns   
| 6
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<18>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.298ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<19>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.122ns   
| 6
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "ad<19>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 13.926ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<1>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 7.999ns   
| 5
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<1>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.880ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<20>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.022ns   
| 5
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<20>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.588ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<21>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.979ns   
| 5
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<21>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.772ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<22>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.675ns   
| 5
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<22>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.639ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<23>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.775ns   
| 5
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<23>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.150ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<24>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.061ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<24>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.157ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<25>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.621ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<25>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.837ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<26>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.879ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<26>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.045ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<27>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.870ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<27>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.844ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<28>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.633ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<28>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.831ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<29>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 6.708ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<29>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.448ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<2>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 5.982ns   
| 3
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<2>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.493ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<30>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.127ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<30>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.320ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<31>" OFFSET = IN 7 nS  BEFORE CO | 7.000ns    | 7.067ns   
| 4
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<31>" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.768ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<3>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 4.989ns   
| 3
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<3>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.430ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<4>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 4.718ns   
| 3
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<4>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.176ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<5>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 5.181ns   
| 4
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<5>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.659ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<6>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 6.666ns   
| 4
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<6>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.233ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<7>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 5.465ns   
| 4
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<7>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 16.103ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<8>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 7.408ns   
| 4
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<8>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 16.064ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
  COMP "AD<9>" OFFSET = IN 7 nS  BEFORE COM | 7.000ns    | 6.578ns   
| 4
  P "CLK"                                   |            |           
|
--------------------------------------------------------------------------------
* COMP "AD<9>" OFFSET = OUT 11 nS  AFTER CO | 11.000ns   | 15.586ns  
| 3
  MP "CLK"                                  |            |           
|
--------------------------------------------------------------------------------
* COMP "DEVSEL_n" OFFSET = OUT 11 nS  AFTER | 11.000ns   | 14.705ns  
| 3
  COMP "CLK"                                |            |           
|
--------------------------------------------------------------------------------
  COMP "INTA_n" OFFSET = OUT 11 nS  AFTER C |            |           
|
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "PAR" OFFSET = IN 7 nS  BEFORE COMP  | 7.000ns    | 6.006ns   
| 5
  "CLK"                                     |            |           
|
--------------------------------------------------------------------------------
* COMP "PAR" OFFSET = OUT 11 nS  AFTER COMP | 11.000ns   | 12.504ns  
| 2
   "CLK"                                    |            |           
|
--------------------------------------------------------------------------------
* COMP "PERR_n" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 12.828ns  
| 2
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "SERR_n" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 12.190ns  
| 2
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "STOP_n" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 14.358ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
* COMP "TRDY_n" OFFSET = OUT 11 nS  AFTER C | 11.000ns   | 15.560ns  
| 3
  OMP "CLK"                                 |            |           
|
--------------------------------------------------------------------------------
  COMP "User_LED" OFFSET = OUT 11 nS  AFTER |            |           
|
   COMP "CLK"                               |            |           
|
--------------------------------------------------------------------------------
  OFFSET = IN 7 nS  BEFORE COMP "CLK"       |            |           
|
--------------------------------------------------------------------------------
  OFFSET = OUT 11 nS  AFTER COMP "CLK"      |            |           
|
--------------------------------------------------------------------------------


54 constraints not met.
Dumping design to file *********.ncd.


All signals are completely routed.

Total REAL time to PAR completion: 30 mins 10 secs 
Total CPU time to PAR completion: 30 mins 10 secs 

Placement: Completed - No errors found.
Routing: Completed - No errors found.
Timing: Completed - 87 errors found.

PAR done.
***********************************************************************

Article: 36338
Subject: Re: Virtex2 gate-level simulation: SDF and timing errors
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 07 Nov 2001 01:20:50 GMT
Links: << >>  << T >>  << A >>
On 6 Nov 2001 06:42:09 -0800, assaf_sarfati@yahoo.com (Assaf Sarfati)
wrote:

>Hi everyone,
>
>I am trying to simulate the gate-level VHDL file generated by Xilinx
>P&R tools. My test design is a bunch of counters connected to an 
>inferred distributed-RAM. The target device is a Virtex-2 chip.
>
>When I simulate the gate-level VHDL by itself, I get timing violation 
>warnings (sometimes) when writing to the distributed-RAM; watching the
>simulator waveforms, it appears that the clock to the RAM has a 100-pS
>phase difference to the counters' clock (the clock is routed as a 
>global clock net).
>
>When I add the gate-level SDF file to the simulation, all the timing
>violation warnings disappear (for all cases: min, max and typ).
>
>Trying to trace the generated VHDL code, I see that signals are routed
>through buffer entities, with built-in delays; apparently the VHDL
>design itself contains all required delays.
>
>Why would adding the SDF to the simulation make errors _disappear_? 
>it should be a more thorogh timing-check and find _more_ timing
>errors.
>
>Can anyone explain?

There are clock delays built in to the simprim (& unisim) components
that are present regardless of whether you use the SDF.  These delays
can cause hold time problems, and using the SDF will delay the data
signals sufficiently to avoid the hold time issues.

You can disable these delays in your simulator.  (If using Modelsim,
try vsim +notimingchecks)

Regards,
Allan.

Article: 36339
Subject: Re: 64-bit PCI core for Lattice CPLD?
From: arast@inficom.com (Alex Rast)
Date: Wed, 07 Nov 2001 01:25:33 GMT
Links: << >>  << T >>  << A >>
In article <cc7b0b5f.0111031727.9ebf9a7@posting.google.com>, kevinbraceusenet@hotmail.com (Kevin Brace) wrote:
>I have never used Lattice's devices, so I don't know much about them.
>However, regarding PCI, I don't know how things will go with a CPLD,
>but at least with an FPGA from my experience trying get my own PCI IP
>core to meet timings with Xilinx Spartan-II 150K system gate part, it
>is very hard for a synthesizable (HDL-based) PCI IP core to meeting
>timings of even 33MHz PCI (Tsu = 7ns and Tval (Tco) = 11ns) with only
>automatic Place & Route (in other words, without using a floorplanner
>tool).

Shouldn't be a problem for me. I virtually never use auto P&R anyway, having 
discovered long ago that it does a very poor job, at least for the types of 
designs I tend to integrate. Currently I do the bulk of my design for Virtex 
directly at the hardware level, using FPGA Editor!

>I know that Xilinx and Altera has a PCI IP core that support 66MHz and
>64-bit PCI, but it looks like Xilinx has much more devices supported
>compared to Altera...

Xilinx does seem to have attractive PCI capabilities. In the case of FPGA's 
it's a no-brainer. I'm not sure about their capabilities in CPLD's however, 
and I don't think they have a PCI core for CPLD - after all, their biggest 
CPLD only goes to 288 macrocells.

>Some people may be concerned that an SRAM-based FPGA may not program
>by the time the BIOS starts executing POST (Power On Self Test) code,
>but I am told that an FPGA that can handle PCI can program itself
>within 100ms, before RST# (PCI's reset signal) gets asserted to reset
>all PCI devices.
>POST code will get executed after that.

If that were really a big issue with an FPGA, you could use a 
reconfigurable-logic methodology to load just enough into the FPGA to run 
basic PCI functionality, then with the system up and stable, run a 
reconfiguration to add the extra features.

..
>One problem with 64-bit 66MHz PCI (3V) is that very few systems
>support it compared to ubiquitous 5V 32-bit 33MHz PCI,

Which is IMHO a sad state of affairs. Why can so few companies be brave and 
advance the standards? People won't adopt until somebody takes the lead, and 
if companies won't take the lead until somebody starts to adopt, you have a 
nice little vicious cycle to maintain the status quo. As it is, all our PC's 
in the office have 64-bit Mylex RAID controllers in them anyway, so we're 
already above the power curve. Part of the reason I want to design for 64-bit 
PCI is that the standard requires they be downward compatible with 32-bit. 
That lets us adopt a more forward-thinking technology position for our design 
without stranding legacy customers.

>
>arast@inficom.com (Alex Rast) wrote in message
> news:<ANEE7.153$FU5.365042@news.uswest.net>...
>> Lattice has a core on their site for 32-bit PCI, but I'm wondering if there
> is 
>> available from Lattice or third parties a 64-bit core....

Alex Rast
arast@qwest.net
arast@inficom.com

Article: 36340
Subject: Re: Xilinx Floorplanner Effectiveness
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 6 Nov 2001 18:56:31 -0800
Links: << >>  << T >>  << A >>
"Kevin Neilson" <kevin_neilson@removethis-yahoo.com> wrote in message news:<FxYF7.57327$IR4.31013561@news1.denver1.co.home.com>...
> If you are using the Insight (Xilinx) PCI core, it should come with all the
> UCF files (and perhaps guide files) that include the proper placement to
> meet timing.  Also, if you purchased the PCI core from Insight, that may
> include several hours of support from Insight Design Services, who are the
> PCI experts.
> 

        Yes, I am using Insight Electronics Spartan-II PCI Development
Kit, but I have the cheapest one ($145, only the PCI card) which
doesn't come with a license for the Xilinx LogiCORE PCI IP core (the
kit with the license costs $2000).
I developed my own PCI IP core in Verilog (not schematics like
supposedly Xilinx did), and that is the reason I am asking about good
strategies on how to floorplan the design because it is not meeting
33MHz PCI's timings.
The PCI IP core worked in two actual computers (one with Intel 430TX
chipset and another one with SiS 5598 chipset) despite the fact that
the design didn't meet timings.
However, I am trying to strictly follow (I know no one does) PCI's
specification, therefore, I can't call the thing done until I can meet
timings.



Regards,



Kevin Brace (don't respond to me directly, respond within the
newsgroup)

Article: 36341
Subject: Fifo books
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Wed, 07 Nov 2001 15:03:19 +1100
Links: << >>  << T >>  << A >>
Hi all,

Are there any good books that have (vhdl) fifo designs and
discussion on asynchronous clock domains etc?

Article: 36342
Subject: FPGA suppliers for hobbyists?
From: Scott L. Burris <scott@slb.org>
Date: Wed, 07 Nov 2001 05:24:00 GMT
Links: << >>  << T >>  << A >>
Hi,

Does anyone have any good suppliers for FPGAs in very small
quantities, like 1 or 2?  I'm particularly interested in
the Xilinx Spartan chips.  I just tinker with this stuff
as a hobby, so I'm not looking to buy zillions of parts.
I've previously been able to get older parts, like the XC52XX.
But newer chips seem to be a problem.

I can special order something like the XCS10XL-4PC84C
from Digikey, but their minimum quantity for this is
30 which is $400 worth of chips, ouch!

Yeah, I know Xilinx has a web store, but they only seem
to offer CPLDs, which I already have, and can easily purchase.
I wish they would offer FPGAs in PLCC packages at least....

I can't be the only tinkerer out there with this problem,
so where do you guys get your parts?

Cheers,

Scott

Article: 36343
Subject: XST synthesis
From: "Su We" <sweather1999@yahoo.com>
Date: Wed, 07 Nov 2001 06:30:58 GMT
Links: << >>  << T >>  << A >>
We are designing with mentor's HDL author and want to know if there is and
easy way to convert/copy the HDL files generated by HDL author and
synthesize them in Xilinx's project navigator?

Basically, we are getting errors with leonardo when synthesizing code that
synthesizes fine in xilinx tools.

thanks

SW



Article: 36344
Subject: Re: Verilog vs. VHDL
From: "AME" <0_0_0_0_@pacbell.net>
Date: Tue, 6 Nov 2001 23:36:13 -0800
Links: << >>  << T >>  << A >>
"Antonio Pasini" <pasini.a@libero.it> wrote in message
news:h9UE7.6714$sq5.364844@news.infostrada.it...
> Sorry, I didn't mean to be offensive! English is not my native language;
> sure "whining" was not the right term.


No need to apologize.  I wasn't offended at all.  Just wanted to make sure
nobody thought I was insane after reading all this stuff about "how it
should be".  :-)

--
-Martin

To send private email:
0_0_0_0_@ <delete this part> pacbell.net
where    "0_0_0_0_"  =  "martineu"





Article: 36345
Subject: Re: FPGA suppliers for hobbyists?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 07 Nov 2001 07:46:37 GMT
Links: << >>  << T >>  << A >>
I think you can still get single quantities from avnet.
http://www.avnetmarshall.com/dynamic/search

"Scott L. Burris" wrote:

> Hi,
>
> Does anyone have any good suppliers for FPGAs in very small
> quantities, like 1 or 2?  I'm particularly interested in
> the Xilinx Spartan chips.  I just tinker with this stuff
> as a hobby, so I'm not looking to buy zillions of parts.
> I've previously been able to get older parts, like the XC52XX.
> But newer chips seem to be a problem.
>
> I can special order something like the XCS10XL-4PC84C
> from Digikey, but their minimum quantity for this is
> 30 which is $400 worth of chips, ouch!
>
> Yeah, I know Xilinx has a web store, but they only seem
> to offer CPLDs, which I already have, and can easily purchase.
> I wish they would offer FPGAs in PLCC packages at least....
>
> I can't be the only tinkerer out there with this problem,
> so where do you guys get your parts?
>
> Cheers,
>
> Scott

--
--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: 36346
Subject: How can I use the instance of block RAM of Spartan2 in Synplify?
From: "duola" <deerlux@hotmail.com>
Date: Wed, 7 Nov 2001 00:28:12 -0800
Links: << >>  << T >>  << A >>
I want use RAM in my Spartan2 chip.When I use the instance of block RAM of
Spartan2 as following:

module ram(clk,we,din,dout,addr);
input clk,we;
input [7:0]din;
input [8:0]addr;
output [7:0]dout;
RAMB4_S8
ram0(.WE(we),.EN(1'b0),.RST(1'b0),.WE(we),.ADDR(addr),.DI(din),.DO(dout));
endmodule

But synplify gave me an error"Reference to undefined module RAMB4_S8".Does
Synplify support the Spartan2 family?Why does it not recognize the block RAM
of Spartan2?
Who can tell me?
Thank you!
Deerlux White




Article: 36347
Subject: FPGA Wish list
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Wed, 7 Nov 2001 04:00:29 -0500
Links: << >>  << T >>  << A >>
Are there any fpga's containing high capacity dram's on chip ? There seem to
be quite a few people interfacing to external drams.



Article: 36348
Subject: Encoder timin question
From: cappellainfuocata@yahoo.it (Banana)
Date: 7 Nov 2001 01:17:09 -0800
Links: << >>  << T >>  << A >>
With this encoder if i set an input  count_in , I've the right output
named count_out only on the next edge of the clock, this is no good
for my project, why this happen and how I can modify this encoder to
have the rigth output directly on the same clock edge ???
Thanks 

             Banana


library ieee ;
use ieee.std_logic_1164.all ;

entity encoder is
	port (  
		count_in  : in std_logic_vector(2 downto 0) ;
		reset	  : in std_logic ;
		clk		  : in std_logic ;
		count_out : out std_logic_vector(2 downto 0)
	) ;
end encoder ;
 
architecture encoder_arch of encoder is 
begin
	process(clk, reset , count_in)
	begin
 		if ( reset = '1') then
   			count_out <= "XXX";
			elsif rising_edge(clk) then 
   				case count_in is
      				when "001" => count_out <= "000";
				    when "010" => count_out <= "001";
      				when "100" => count_out <= "010";
      		        when others => NULL;
   				end case;
		end if;
	end process;
end encoder_arch ;

Article: 36349
Subject: Re: FPGA suppliers for hobbyists?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: 7 Nov 2001 09:44:47 GMT
Links: << >>  << T >>  << A >>
Scott L. Burris <scott@slb.org> wrote:
: Hi,

: Does anyone have any good suppliers for FPGAs in very small
: quantities, like 1 or 2?  I'm particularly interested in
: ...

Quicklogic offers their programmed WebAsics for free...

Bye

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search