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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 44975

Article: 44975
Subject: loading Spartan 2E configuration
From: "Jim Raynor" <chris_cheung66@hotmail.com>
Date: Mon, 08 Jul 2002 21:25:30 GMT
Links: << >>  << T >>  << A >>
hi,

    I am going to use the serial slave mode to load the configuration to the
FPGA from the PC via the PCI bus.  For the Spartan 2E device, it said it
need additional 8 cycles to complete the start-up sequences after loading
all the configuration bits.  I was wondering if the .bit file would be
inserted 8 dummy bits automatically to complete the start-up sequences or I
have to write a routine for generating 8 extra CCLK cycles after loading all
the configuration bits?

    Thanks

    Jim Raynor



Article: 44976
Subject: Getting started with FPGAs
From: "Philip Pemberton" <philpem@despammed.com>
Date: Mon, 8 Jul 2002 22:28:53 +0100
Links: << >>  << T >>  << A >>
Hi,
    I've been having a look at Xilinx's website and I'm trying to think of a
(low cost) way to start designing with FPGAs. Right now, I don't care who
makes them as long as said FPGA is reasonably cheap in 1-off quantities and
the devkit/software costs around GBP100 or less.
    Anyone got any suggestions?

Thanks.
--
Phil.
philpem@despammed.com  <<-- Yes, this address is real...
http://www.philpem.dsl.pipex.com/



Article: 44977
Subject: Re: Are these design guideline safe ?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 09 Jul 2002 09:41:02 +1200
Links: << >>  << T >>  << A >>
TED wrote:
> 
> Thanks for the review.
> 
> BTW, the design is not 'over designed', the FPGA/PLD's are. ;-)
> 
> Seriously, this is a straight forward design based on the system
> requirements. The guide lines was defined after the fact as a formal
> tool to analyze the correctness of the design.
> 
> From your answer I presume that any synthesized PLD/ASIC will guaranty
> that if two flip flops gets the same external clock and the output of
> the first feeds the input of the second, the system will behave
> properly (that is,  clock skew will not cause the second flip flop to
> sample the new data of the first flip flop).

A qualified yes. 
 Within a device, this must be true, or counters would not count.

 However, some data sheets quote MIN Ck->Q times that are LESS than the 
MAX hold times. 
 In practice, chips do not operate at both speed corners 
at the same time, on the same die, so this is OK. 
 It is also why a commmon clock doubling scheme, of XOR + FlipFlop 
can work.

 What can occur, that can trip a 'good on paper' design is
- Multiple cascade chips, with a very fast device into a very slow one
- Possible synthesis mix of global and product term clocks

 If you are passing signals between chips, it can pay to use both edges
so the nominal Tsu.Th are a half clock period, and so avoid any 
chance of 'too quick' into 'too slow'.
 
> Tal
> 
> On Mon, 08 Jul 2002 16:20:57 GMT, John_H <johnhandwork@mail.com>
> wrote:
> 
> >The guidelines are safe because they are over-designed.  Note that your
> >thought of partitioning into two groups for rising and falling edge
> >triggered flops violates design guideline #1.

It is OK to have both edges active in a design, and still be safe.
( remembering, of course, that the edge-edge time can now be 1/2 period) 

Often this is safer, esp in cascade designs - look at 74HC4094 etc.

-jg

Article: 44978
Subject: Re: SpartanXL,2E: How many flipflops on one clock-net?
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 08 Jul 2002 14:48:19 -0700
Links: << >>  << T >>  << A >>
Helmut.
There is no limit to the flip-flop loads on a global clock line.
Check the (asynchronous?) inputs to your Finite State Machine. They are
far more likely to cause grief than the clock distribution.

Peter Alfke, Xilinx Applications
============================
Helmut Sennewald wrote:

> Hello,
> we had a problem with the clockbuffer in a Spartan-XCS40XL.
> The state machines sometimes went crazy. It is a one hot design.
> By accident, we fixed the problem by changing the clock buffer
> from the left upper corner to the right lower corner of the chip.
> We have used only one clocknet with 20Mhz for all flipflops.
>
> Now we have transferred the design from XL to Spartan-2E. The
> state machines again behave sometimes crazy.
> I guess we have 1000 or more flipflops on that clock net.
> The power supply voltages are ok.
>
> Is there a limit for the number of flipflops one one clocknet?
>
> Any idea what is going wrong?
>
> Best Regards
> Helmut


Article: 44979
Subject: Re: SpartanXL,2E: How many flipflops on one clock-net?
From: "Helmut Sennewald" <HelmutSennewald@t-online.de>
Date: Tue, 9 Jul 2002 00:13:15 +0200
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
news:3D2A08A2.51ADD3CD@xilinx.com...
> Helmut.
> There is no limit to the flip-flop loads on a global clock line.
> Check the (asynchronous?) inputs to your Finite State Machine. They are
> far more likely to cause grief than the clock distribution.
>

Hello Peter,
thank you for your advice. I am happy to hear that the number of
flipflops on a clockline doesn't matter in that FPGA.

Best Regards
Helmut

> Helmut Sennewald wrote:
>
> > Hello,
> > we had a problem with the clockbuffer in a Spartan-XCS40XL.
> > The state machines sometimes went crazy. It is a one hot design.
> > By accident, we fixed the problem by changing the clock buffer
> > from the left upper corner to the right lower corner of the chip.
> > We have used only one clocknet with 20Mhz for all flipflops.
> >
> > Now we have transferred the design from XL to Spartan-2E. The
> > state machines again behave sometimes crazy.
> > I guess we have 1000 or more flipflops on that clock net.
> > The power supply voltages are ok.
> >
> > Is there a limit for the number of flipflops one one clocknet?
> >
> > Any idea what is going wrong?
> >
> > Best Regards
> > Helmut
>


Article: 44980
Subject: ISE 4.2i : Clock Buffer Disable
From: "Jeremy Whatley" <jeremyw@erlangtech.com>
Date: Mon, 8 Jul 2002 15:15:52 -0700
Links: << >>  << T >>  << A >>
How do you disable the automatic clock buffer insertion with ISE 4.2i?

Article: 44981
Subject: Re: ISE 4.2i : Clock Buffer Disable
From: Duane Clark <junkmail@junkmail.com>
Date: Mon, 08 Jul 2002 15:24:12 -0700
Links: << >>  << T >>  << A >>
Jeremy Whatley wrote:
> How do you disable the automatic clock buffer insertion with ISE 4.2i?

In VHDL?

    attribute clock_buffer: string;
    attribute clock_buffer of ASn: signal is "ibuf";


-- 
My real email is akamail.com@dclark (or something like that).


Article: 44982
Subject: Re: Getting started with FPGAs
From: Mark <Mark@HVWTech.com>
Date: Mon, 08 Jul 2002 22:56:27 GMT
Links: << >>  << T >>  << A >>
In article <agd0ni$kfjfd$1@ID-122086.news.dfncis.de>, 
philpem@despammed.com says...
> Hi,
>     I've been having a look at Xilinx's website and I'm trying to think of a
> (low cost) way to start designing with FPGAs. Right now, I don't care who
> makes them as long as said FPGA is reasonably cheap in 1-off quantities and
> the devkit/software costs around GBP100 or less.
>     Anyone got any suggestions?
> 

Altera -not Xilinx- but really easy to use:

http://www.hvwtech.com/intro-fpga.htm


Article: 44983
Subject: Virtex-II PRO Channel alignment not working?
From: <dano1@attglobal.net>
Date: Mon, 8 Jul 2002 21:43:22 -0400
Links: << >>  << T >>  << A >>
Is it true that the multi-channel fifo-allignment for the SERDES is not
functional in the VII-PRO? Does anyone know what the isue is in detail? Can
two channels be aligned ?

Thanks,
Dan



Article: 44984
Subject: Re: Virtex reset signal internaly hold?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 09 Jul 2002 01:56:54 GMT
Links: << >>  << T >>  << A >>
Hmm, post route sim is going to have the delays in it.  The global reset
routing has a pretty big delay on it, which unless your clock cycle is
pretty long is going to take multiple clock cycles to reach its
destinations.  If you are using the DLL, you'll also want to wait until it
has locked.

Holger Kleinegraeber wrote:

> Hello,
>
> I am encountering differences between the Behavioral- and Post
> Place&Route-Simulation. I am targeting a Virtex2 device.
> When assigning the reset signal for one clock (the first clock in
> simulation), it seems this signal is internaly active for two or three
> clocks. Could this be possible or is this a completely different effect?
> Is this the simulation of the Startup-Sequence of the FPGA?
>
> Greetings,
>    Holger

--
--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: 44985
Subject: Re: ISE 4.2i : Clock Buffer Disable
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 08 Jul 2002 22:21:52 -0500
Links: << >>  << T >>  << A >>


Jeremy Whatley wrote:
> 
> How do you disable the automatic clock buffer insertion with ISE 4.2i?


        Which synthesis tool are you using?
In case you are using XST, if you uncheck Add I/O Buffers option, it
won't attach any I/O pads to your design, including clock buffers
(GCLKBUF).


Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 44986
Subject: Re: How can I preserve FFs in LeonardoSpectrum?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 08 Jul 2002 22:36:19 -0500
Links: << >>  << T >>  << A >>
        After one week of struggle, I finally found a solution to my
problem . . .
It turns out, in LeonardoSpectrum, the only way to prevent duplicate FF
from getting removed is to use preserve_signal primitive, but there is a
catch to it.
Consider the Verilog code below.

__________________________________________________
module noreg (a, clock, b, c);

input a, clock;
output b, c;
reg    b, c;

always @ (posedge clock)
  begin
     b = a;
     c = a;
  end
endmodule
__________________________________________________


        When the above code is synthesized by LeonardoSpectrum,
LeonardoSpectrum will remove either 'b' or 'c' FF because it thinks 'b'
and 'c' FFs are identical.
To prevent that from happening, I will use preserve_signal, which will
look like this.


__________________________________________________
module noreg (a, clock, b, c);

input a, clock;
output b, c;
reg    b, c;

// exemplar attribute b preserve_signal true
// exemplar attribute c preserve_signal true

always @ (posedge clock)
  begin
     b = a;
     c = a;
  end
endmodule



__________________________________________________


        But the problem is, when the FF name and the output port name
match, the preserve_signal attribute will be ignored even if it is
attached.
So, with the above example, either b or c FF will be optimized away.
That's a huge problem for FFs being attached to I/O pads.
After one week of struggle, I finally found a document that addresses my
problem . . . , but I don't like the way it works . . . 


__________________________________________________
module keepreg (a, b, c, clock);

input a, clock;
output b, c;
reg    breg, creg;

// exemplar attribute breg preserve_signal true
// exemplar attribute creg preserve_signal true

assign b = breg;
assign c = creg;

always @ (posedge clock) 
 begin
   breg = a;
   creg = a;
 end

 endmodule
__________________________________________________


        All of the code shown above except the one I added two lines of
"// exemplar attribute" came from a PDF file (Around Page 89) I found at
Mentor Graphics website. (I copied the code for illustrative purposes.)

http://www.mentor.com/leonardospectrum/app-notes/advanced_synthesis.pdf 


Basically, what the slides are saying is that in order to prevent
equivalent FF removal, the FF name and the output port name must not be
the same, otherwise preserve_signal attribute will be ignored.
In my case, my code looks like the second example where the FF name and
the output port name match, and XST (Xilinx Synthesis Technology) I use
can constrain equivalent FF fine by attaching
equivalent_register_removal attribute to individual FFs.
Because the design I am working on is largely done, and only awaits
extensive testing, I am not willing to make modifications just to
accommodate LeonardoSpectrum.
The work around of this equivalent FF removal issue with
LeonardoSpectrum will be to edit an EDIF file generated by it with a
text editor, and manually duplicate FFs myself.
I don't like editing an EDIF file with a text editor, but I rather do
that than having to modify my design.
Editing an EDIF file with a text editor takes about 20 minutes.
        After wasting one week on this issue, I have to wonder why
Mentor Graphics/Exemplar Logic not mention this caveat in their manuals?
None of the manuals that came with LeonardoSpectrum-Altera mentioned
anything about this issue, and after doing lots of searches with search
engines, I finally found slides that discussed this issue.
Also, why can't the FF name and the output port name be the same just to
constrain equivalent FFs?
I believe in Verilog, it is fairly common to have the FF name and the
output port name to be the same.
Therefore, why can't the synthesis tool accommodate this?
        Another thing I noticed affecting only Altera designs is that,
LeonardoSpectrum has an undocumented (Manual that came with
LeonardoSpectrum-Altera don't discuss it.) synthesis variable called
"alt_push_inv_through_reg" set to TRUE.
This option sounds similar to "NOT gate push back" feature of Altera
in-house synthesis tool.
As the name suggests, this "alt_push_inv_through_reg" in some cases will
put a LUT (LUT will act as an inverter.) after a FF (Q output of a FF
gets attached to LUT.).
The problem of this feature is, it can prevent a FF from being merged
into an IOE and because the LUT has some delay, it will worsen Tco
(Clock-to-Output).
"Your Project File Name".scr has this "alt_push_inv_through_reg"
variable, and changing it to FALSE will turn it off.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Kevin Brace wrote:
> 
>         Does anyone know how I can preserve FFs in LeonardoSpectrum?
> When I synthesize a design with LeonardoSpectrum, it aggressively
> removes FFs it considers equivalent, which is fine normally, but this
> becomes a major problem when writing a constraint file for Quartus II.
> I read LeonardoSpectrum Reference Manual, but I am not sure which
> keyword I should use to prevent equivalent FF removal, and the syntax of
> a constraint file.
> 
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)

Article: 44987
Subject: Re: Inserting flops to help timing (in Virtex-II)
From: "Lee Khoon" <lktan24@hotmail.com>
Date: Mon, 8 Jul 2002 21:19:34 -0700
Links: << >>  << T >>  << A >>
Hi,
I encountered the following error while implementing the Flow Engine:
ERROR:Pack:18 - The design is too large for the given device and package. 
   
If the slice count exceeds device resources you might try to disable
register ordering (-r).  Also if your design contains AREA_GROUPs, you may be able to improve density by adding COMPRESSION to your AREA_GROUPs if you haven't done so already.

I would like to know where can I:
1)disable register ordering in the Xilinx Design Manager->Flow Engine; where do I change the map command line to include option -r?

2) add COMPRESSION to AREA_GROUPs 

I really need help in these urgently.
Any advice will be greatly appreciated.

Thanks you very much in advance.

Regards,
Lee Khoon

Article: 44988
Subject: Xilinx adder RLOCs
From: John_H <johnhandwork@mail.com>
Date: Mon, 08 Jul 2002 22:31:23 -0700
Links: << >>  << T >>  << A >>
My initial attempts appear to be producing ugly results - any guidance
is appreciated.

I'm trying to RLOC three adders (two adders feeding the third) in a
Spartan-II device along with associated input and output registers.  I'm
synthesizing my Verilog code with Synplify but I'm trying to apply all
the RLOC information in the UCF.  Since Synplify dynamically renames
combinatorial primitives, I'm left trying to imply the locations through
the registers.

Is there a better way?

I'd hate to implement my adders as dedicated modules.  I may have to go
there to explicitly define all the elements and keep MAP happy.

What is needed to get a carry chain - LUTs, MUXCYs, XORCYs - and
optional output registers to place with the RLOCs?  I tried specifying
the registers associated with the carries but didn't quite get the
chains to accompany the registers in the manner I expected.

It seems the RLOC_RANGE attribute is intended for all RLOC elements
within a module and is an absolute row/column reference.  While the
RLOC_RANGE allows wildcards, it doesn't appear that the RLOC allows a
wildcard.  Would I be able to wildcard the (probable) base name that
Synplify gives the chain and provide an RLOC list?  Since
"LOC=Y19,AA17,AB21" is a valid form of the LOC command, perhaps a list
would work for RLOC.

For "assign A_gt_B = A > b;" perhaps:

INST A_gt_B_* RLOC=R0C0.S0,R1C0.S0,R2C0.S0,R3C0.s0;

??

I envision MAP complaining about too much going into one slice;  I'll
find out in the morning.  Any experiences in getting the mapper and P&R
to cooperate (given the synplify front end) would be helpful.

Thanks,
John_H

Article: 44989
Subject: Re: Are these design guideline safe ?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 09 Jul 2002 08:05:45 +0100
Links: << >>  << T >>  << A >>


TED wrote:

> From your answer I presume that any synthesized PLD/ASIC will guaranty
> that if two flip flops gets the same external clock and the output of
> the first feeds the input of the second, the system will behave
> properly (that is,  clock skew will not cause the second flip flop to
> sample the new data of the first flip flop).
>
> Tal
>

This is correct for CPLD/FPGA where

Tco(min) + routing(min) > Thld + ClkSkew(max)

is always true for FFs in the same clock domain => the hold time is "guaranteed
by design".

It is *not* necessarily true for ASICs and so there can be a "fix hold" pass
where extra buffers need to be inserted, which might cause setup time problems
elsewhere, and fixing those might mean new hold time problems ... getting this
loop to converge is called "achieving timing closure".


Article: 44990
Subject: Re: Xilinx adder RLOCs
From: Russell <rjshaw@iprimus.com.au>
Date: Tue, 09 Jul 2002 17:10:32 +1000
Links: << >>  << T >>  << A >>
John_H wrote:
> 
> My initial attempts appear to be producing ugly results - any guidance
> is appreciated.
> 
> I'm trying to RLOC three adders (two adders feeding the third) in a
> Spartan-II device along with associated input and output registers.  I'm
> synthesizing my Verilog code with Synplify but I'm trying to apply all
> the RLOC information in the UCF.  Since Synplify dynamically renames
> combinatorial primitives, I'm left trying to imply the locations through
> the registers.
> 
> Is there a better way?
> 
> I'd hate to implement my adders as dedicated modules.  I may have to go
> there to explicitly define all the elements and keep MAP happy.
> 
> What is needed to get a carry chain - LUTs, MUXCYs, XORCYs - and
> optional output registers to place with the RLOCs?  I tried specifying
> the registers associated with the carries but didn't quite get the
> chains to accompany the registers in the manner I expected.

I tried for months, but the floorplanner (4.2i) is basically broken for
manual routing. One of the bugs is that manually placed carry chains
become 'unstuck'. I'm told that they're still there if you inspect it
in fpga editor. The next major release of webpack is supposed to fix
all these things.

> It seems the RLOC_RANGE attribute is intended for all RLOC elements
> within a module and is an absolute row/column reference.  While the
> RLOC_RANGE allows wildcards, it doesn't appear that the RLOC allows a
> wildcard.  Would I be able to wildcard the (probable) base name that
> Synplify gives the chain and provide an RLOC list?  Since
> "LOC=Y19,AA17,AB21" is a valid form of the LOC command, perhaps a list
> would work for RLOC.
> 
> For "assign A_gt_B = A > b;" perhaps:
> 
> INST A_gt_B_* RLOC=R0C0.S0,R1C0.S0,R2C0.S0,R3C0.s0;
> 
> ??
> 
> I envision MAP complaining about too much going into one slice;  I'll
> find out in the morning.  Any experiences in getting the mapper and P&R
> to cooperate (given the synplify front end) would be helpful.
> 
> Thanks,
> John_H

Article: 44991
Subject: how to keep info. in RAM during reconfiguration?
From: =?iso-8859-1?Q?St=E9phane?= Guyetant <sguyetan @nospam.irisa.fr>
Date: Tue, 09 Jul 2002 10:44:56 +0200
Links: << >>  << T >>  << A >>
Say we have a SDRAM (Micron 256Mb) connected to a FPGA (Spartan II).
We want to keep the information in RAM after reconfiguration (obviously,
the SDRAM controller is the same).

Is it sufficient to pull-down (10K) the CKE pin of the RAM chip to drive
it low during reconfiguration, as all other pins are in high impedance
state?

If not, do you see any other solution than partial reconfiguration?

Thanks,
Stephane


Article: 44992
Subject: Re: CLK/2
From: xueqing <seabedj@163.com>
Date: Tue, 9 Jul 2002 02:19:30 -0700
Links: << >>  << T >>  << A >>
You may try this way in VHDL:
begin
 U1:IBUF port map(CLKIN,CLK);
 process(clk)
 begin
   if clk'event and clk='1'then
       clk2d<=not clk2d;
   end if;
 end process;
 U2:BUFG port map(clk2d,clk2d_out);

Article: 44993
Subject: Re: Multiple constraints, same net?
From: seabedj163.com <>
Date: Tue, 9 Jul 2002 03:05:35 -0700
Links: << >>  << T >>  << A >>
You may try this way:set constraints to clk period 10ns,then create all third filter nets into a group(say,"thid_g"),then set constraint on this group:
TIMESPEC "TS_a"=FROM "third_g" TO "third_g" 20ns;---Constraint FROM_TO format comes before PERIOD in priority order.

Article: 44994
Subject: Re: How can I preserve FFs in LeonardoSpectrum?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 09 Jul 2002 12:02:24 GMT
Links: << >>  << T >>  << A >>
Kevin,

Synplicity has a similar behavior.  To work around it, you either need to
create an internal signal then copy that to the port, or you can put syn_keeps
on the D signal of each flip-flop:

1)
port(
    q: out std_logic_vector(2 downto 0); --duplicated output port



signal q_i:std_logic_vector(2 downto 0);
signal d: std_logic;
signal dd:std_logic_vector(2 downto 0);

attribute syn_preserve of q_i:signal is true;

begin
    q<= q_i;

    process(clk)
       begin
                 :
         q_i<=(others=>d);


OR

    attribute syn_keep of dd:signal is true;

begin
    dd<=(others=>d);
    :
    :
    process(clk)
        :
        :
        q<=dd;

The latter was necessary in earlier versions of synplicity where syn_preserve
did not work properly.


Kevin Brace wrote:

>         After one week of struggle, I finally found a solution to my
> problem . . .
> It turns out, in LeonardoSpectrum, the only way to prevent duplicate FF
> from getting removed is to use preserve_signal primitive, but there is a
> catch to it.
> Consider the Verilog code below.
>
> __________________________________________________
> module noreg (a, clock, b, c);
>
> input a, clock;
> output b, c;
> reg    b, c;
>
> always @ (posedge clock)
>   begin
>      b = a;
>      c = a;
>   end
> endmodule
> __________________________________________________
>
>         When the above code is synthesized by LeonardoSpectrum,
> LeonardoSpectrum will remove either 'b' or 'c' FF because it thinks 'b'
> and 'c' FFs are identical.
> To prevent that from happening, I will use preserve_signal, which will
> look like this.
>
> __________________________________________________
> module noreg (a, clock, b, c);
>
> input a, clock;
> output b, c;
> reg    b, c;
>
> // exemplar attribute b preserve_signal true
> // exemplar attribute c preserve_signal true
>
> always @ (posedge clock)
>   begin
>      b = a;
>      c = a;
>   end
> endmodule
>
> __________________________________________________
>
>         But the problem is, when the FF name and the output port name
> match, the preserve_signal attribute will be ignored even if it is
> attached.
> So, with the above example, either b or c FF will be optimized away.
> That's a huge problem for FFs being attached to I/O pads.
> After one week of struggle, I finally found a document that addresses my
> problem . . . , but I don't like the way it works . . .
>
> __________________________________________________
> module keepreg (a, b, c, clock);
>
> input a, clock;
> output b, c;
> reg    breg, creg;
>
> // exemplar attribute breg preserve_signal true
> // exemplar attribute creg preserve_signal true
>
> assign b = breg;
> assign c = creg;
>
> always @ (posedge clock)
>  begin
>    breg = a;
>    creg = a;
>  end
>
>  endmodule
> __________________________________________________
>
>         All of the code shown above except the one I added two lines of
> "// exemplar attribute" came from a PDF file (Around Page 89) I found at
> Mentor Graphics website. (I copied the code for illustrative purposes.)
>
> http://www.mentor.com/leonardospectrum/app-notes/advanced_synthesis.pdf
>
> Basically, what the slides are saying is that in order to prevent
> equivalent FF removal, the FF name and the output port name must not be
> the same, otherwise preserve_signal attribute will be ignored.
> In my case, my code looks like the second example where the FF name and
> the output port name match, and XST (Xilinx Synthesis Technology) I use
> can constrain equivalent FF fine by attaching
> equivalent_register_removal attribute to individual FFs.
> Because the design I am working on is largely done, and only awaits
> extensive testing, I am not willing to make modifications just to
> accommodate LeonardoSpectrum.
> The work around of this equivalent FF removal issue with
> LeonardoSpectrum will be to edit an EDIF file generated by it with a
> text editor, and manually duplicate FFs myself.
> I don't like editing an EDIF file with a text editor, but I rather do
> that than having to modify my design.
> Editing an EDIF file with a text editor takes about 20 minutes.
>         After wasting one week on this issue, I have to wonder why
> Mentor Graphics/Exemplar Logic not mention this caveat in their manuals?
> None of the manuals that came with LeonardoSpectrum-Altera mentioned
> anything about this issue, and after doing lots of searches with search
> engines, I finally found slides that discussed this issue.
> Also, why can't the FF name and the output port name be the same just to
> constrain equivalent FFs?
> I believe in Verilog, it is fairly common to have the FF name and the
> output port name to be the same.
> Therefore, why can't the synthesis tool accommodate this?
>         Another thing I noticed affecting only Altera designs is that,
> LeonardoSpectrum has an undocumented (Manual that came with
> LeonardoSpectrum-Altera don't discuss it.) synthesis variable called
> "alt_push_inv_through_reg" set to TRUE.
> This option sounds similar to "NOT gate push back" feature of Altera
> in-house synthesis tool.
> As the name suggests, this "alt_push_inv_through_reg" in some cases will
> put a LUT (LUT will act as an inverter.) after a FF (Q output of a FF
> gets attached to LUT.).
> The problem of this feature is, it can prevent a FF from being merged
> into an IOE and because the LUT has some delay, it will worsen Tco
> (Clock-to-Output).
> "Your Project File Name".scr has this "alt_push_inv_through_reg"
> variable, and changing it to FALSE will turn it off.
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)
>
> Kevin Brace wrote:
> >
> >         Does anyone know how I can preserve FFs in LeonardoSpectrum?
> > When I synthesize a design with LeonardoSpectrum, it aggressively
> > removes FFs it considers equivalent, which is fine normally, but this
> > becomes a major problem when writing a constraint file for Quartus II.
> > I read LeonardoSpectrum Reference Manual, but I am not sure which
> > keyword I should use to prevent equivalent FF removal, and the syntax of
> > a constraint file.
> >
> > Kevin Brace (In general, don't respond to me directly, and respond
> > within the newsgroup.)

--
--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: 44995
Subject: Re: Multiple constraints, same net?
From: Stephan Neuhold <stephan.neuhold@xilinx.com>
Date: Tue, 09 Jul 2002 13:44:30 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------91C9A1D624D57EFDC5D761EE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

The path that gets analysed by the tools is the one that appears last in the
.pcf (Physical Constraints File). If you open this file in a text-editor, I
expect you would find the constraint for Slo_Clk appear after the one for Clk.
Now, because they are one and the same net, analysis of only one of the
constraints, whether it be Clk or Slo_Clk, is necessary. In general, If you put
the tighter constraint on the Clk net and it is met, then the slower constraint
will also meet timing.

Since the Slo_Clk cct appears to be a multi-cycle path there is another
possibility. You could create a group incorporating all synchronous elements
that are clocked by Slo_Clk (or perhaps they all have the same enable signal,
then you can create this group by using this signal). After you have grouped all
synch elements, put a FROM TO constraint on these paths as follows:

NET "Slo_Clk" TNM = SLOW_CCT; ##This creates the group
TIMESPEC "TS_SLOW_CCT" = FROM "SLOW_CCT" TO "SLOW_CCT" 20 ns;  ##This creates
the multi-cycle timing specification.

Be aware, that a FROM TO constraint has higher priority than the PERIOD
constraint, so PAR will work on the "SLOW" section first. But the tools are
smart enough to see, that this part of the cct runs slower than the PERIOD of
Clk = 10 ns and takes this into account.

--Stephan

Clark Pope wrote:

> Background: Xilinx ISE, VHDL, VirtexII
>
> I am trying do something that should be simple. I have one clock line
> feeding 3 filter sections. I need the first two filter sections routed to a
> 10 ns period spec. The last filter section only needs to route to 20 ns(it's
> shut down when operating at fastest rate).
>
> I thought I could just get by using by renaming the clock into the third
> section, i.e.
>
> Slo_Clk <= Clk;
>
> First two sections use Clk and the last section uses Slo_Clk. My .ucf is set
> up to constrain Clk to 10ns and Slo_Clk to 20ns.
>
> The design compiles and PARs fine. The timing analysis, however, only shows
> the request/actual times for Slo_Clk so I have no way of knowing whether the
> fast clock really works to 10 ns. Should I assume because no timing errors
> were reported that the 10ns spec was met? Is it possible that the PAR used
> 20 ns for both Clk and Slo_Clk? Any suggestions for a better way to do this?
>
> Thanks,
> Clark Pope



Article: 44996
Subject: DCM - LOCKED output stays high when it shouldn't?
From: haklis@hotmail.com (Hakon Lislebo)
Date: 9 Jul 2002 06:05:19 -0700
Links: << >>  << T >>  << A >>
Hi, I mean that I have read that the Xilinx DCM - LOCKED output stays,
or goes high again after the DCM has lost lock. Is that correct? Does
anybody have a link to some documentation?

Thank you
Regards
Hakon Lislebo

Article: 44997
Subject: Re: DCM - LOCKED output stays high when it shouldn't?
From: Stephan Neuhold <stephan.neuhold@xilinx.com>
Date: Tue, 09 Jul 2002 14:11:15 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------50B150816600990FDED25DBA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Hakon,

Documentation on the DCM can be found at:
http://www.xilinx.com/products/virtex/handbook/ug002_ch2_dcm.pdf

Regards,
Stephan

Hakon Lislebo wrote:

> Hi, I mean that I have read that the Xilinx DCM - LOCKED output stays,
> or goes high again after the DCM has lost lock. Is that correct? Does
> anybody have a link to some documentation?
>
> Thank you
> Regards
> Hakon Lislebo



Article: 44998
Subject: test sign
From: "Benoit" <benoit.hamon@elios-informatique.fr>
Date: Tue, 9 Jul 2002 15:28:38 +0200
Links: << >>  << T >>  << A >>
Hi,

I need doing this operation (VHDL with Quartus II) :
S(44 downto 0) = A(44 downto 0) - B(44 downto 0)
This sub is with an Altera APEX EP20K600E-2x    (20 MHz of Clock).

Can you tell me :
=> How do Quartus to integrate this code in the FPGA ( complement on two ,
...) ?.
=> How test sign (pos or neg) => if bit(44)='0' then "pos" else "neg" ?.
=> 50ns is enough time to Sub this bus ?.

Thanks in advance,
Regards,

Benoit



Article: 44999
Subject: Re: Routing Virtex-II 256 pin BGA on 4 layers
From: emanuel stiebler <emu@ecubics.com>
Date: Tue, 09 Jul 2002 08:33:52 -0600
Links: << >>  << T >>  << A >>
Manfred Kraus wrote:
> 
> Hi Steve,
> I had the same doubts when I tried to route an BG256 with only 4 Layers.
> In principle it is possible, but your pcb design will violate almost all
> rules
> for decoupling and EMI.  Since I didnt want to take a risk, I switched
> to 6 Layers. Everything was fine.
> Please tell me your experiences, if you decide to use only 4 Layers.

So, you took one layer for VCC_INT ?

Just asking, because I'm having problems to route a SpartanIIe-FG456
on 6 layers. Looks like I need 8 :-(

cheers



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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