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 136100

Article: 136100
Subject: Re: classic Spartan-3 DDR2 and IOBs
From: "Dan Kuechle" <danielgk@visi.com>
Date: Fri, 31 Oct 2008 11:12:50 -0600
Links: << >>  << T >>  << A >>

"Eric" <jonas@mit.edu> wrote in message 
news:bbf396a8-4678-461d-90b8-e29b26b165c7@v13g2000pro.googlegroups.com...
>
> Rob,
>   This is fantastic help, esp. since I just got quotes on IBIS
> simulators that exceed my
> entire budget for this project. :) I'm shooting for somewhere between
> 125 MHz and 150 MHz
> for my clock, and plan on having a very simple, bursty interface.
> I'm basically trying to clock this thing as slowly as I possibly can.
> I am using a single DDR2
> IC (16-bit wide) per interface which will be directly connected to the
> FPGA as closely as possible.
>
> For the control signals, you recommend SSTL18_I_DCI on the FPGA side
> and a pull-up
> to VTT on the DDR2 side.
>
> You're then recommending using the SSTL_18_II IO standard for the DQ/
> DQS signals on
> the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just
> using ODT on
> the DDR2 side.
>
> If I understand correctly we can't use ODT for the address/control
> signals on the DDR2 side
> because DDR2 only supports ODT on data-related signals.
>
> For your interface, did you use the Xilinx Memory Interface generator,
> or do your own interface
> by hand? MIG tries to place what seem like significant restrictions on
> pin location, as well
> as being a bit too general-purpose for our applications, but I'm
> guessing if there
> are pin constraints there's a reason for it.
>
> Also, may I ask how far away your DDR2 ICs were from your FPGA, and if
> there was only
> a single IC per interface or multiple ICs?
>
>
> Thanks,
>   ...Eric
>
Eric

Have you looked into running slower than 125 mhz (with the dll disabled)?  I 
want to do this, at probably around 33mhz, but I'm having trouble getting 
any information about it:  namely can I do it and will it work?  Just 
wondering if you knew anything about that.

Dan 



Article: 136101
Subject: GDDR3
From: "Pete Fraser" <pfraser@covad.net>
Date: Fri, 31 Oct 2008 10:48:39 -0700
Links: << >>  << T >>  << A >>
Anybody had success in interfacing GDDR3 memory
to FPGAs? If so, how did you do it, and what sort
of performance did you achieve?

Thanks

Pete 



Article: 136102
Subject: Re: ISE 9.2.03i problem
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 31 Oct 2008 10:56:00 -0700
Links: << >>  << T >>  << A >>
KJ wrote:

> As always (and I'm assuming that Mark has already done this), you
> always run the simulator first to make sure that the design is
> functionally correct.  Optimization that changes the observable
> function is incorrect optimization.

Yes. It is not the job of synthesis to guess
the cases where I don't want register sharing or duplication.
If the netlist sims correctly, synthesis is correct.

To get a register to duplicate or not share as
I wish, I have to describe the requirement
as a device constraint, or change my logical description
to rule out the unwanted register usage.

For example, if I want to avoid sharing of the
second register in a synchronizer, I could
either make an explicit device-specific constraint,
or add a third flop to the synchronizer.

       -- Mike

Article: 136103
Subject: Re: PLBv4.6 with more than 16 slaves
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 31 Oct 2008 15:25:36 -0400
Links: << >>  << T >>  << A >>
Hi Ales,

> I have been using a DCR bus and I like it, but it will become obsolete
> soon.

Could you please elaborate on what you know about DCR obsolescence?

> As far as I know MPMC bus bridging was removed from the core.

Yeah, you are right, I forgot about it. I am still using MPMC2...



/Mikhail



Article: 136104
Subject: Re: system verilog state machine
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 31 Oct 2008 22:11:28 +0000
Links: << >>  << T >>  << A >>
On Tue, 28 Oct 2008 09:38:18 -0500, "maxascent"
<maxascent@yahoo.co.uk> wrote:

>
>Hi
>
>I am trying to write a state machine in system verilog. I am using an enum
>for the states e.g.
>
>enum logic [1:0] {one, two, three} state, next; 
>
>I have a sequential process which init the state to one e.g.
>
>always_ff @(posedge clk)
>begin
>  if (~reset_n) begin
>    state <= one;
>  end else begin
>    state <= next;
>  end
>end
>
>When I try and sythesise it usingg Synplify it complains that :-
>
>Initial value is not supported on state machine state
>
>It doesnt seem to like the state <= one;
>
>I dont understand what is wrong with this, can anybody help?

I'm not sure, but I suspect it's the fact that you do not
have an *asynchronous* reset on "state".  I can't easily
see anything wrong with what you've done.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 136105
Subject: Re: classic Spartan-3 DDR2 and IOBs
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 01 Nov 2008 02:16:23 +0000
Links: << >>  << T >>  << A >>
On Fri, 31 Oct 2008 11:12:50 -0600, "Dan Kuechle" <danielgk@visi.com>
wrote:


>
>Have you looked into running slower than 125 mhz (with the dll disabled)?  I 
>want to do this, at probably around 33mhz, but I'm having trouble getting 
>any information about it:  namely can I do it and will it work?  Just 
>wondering if you knew anything about that.

Check a DDR2 memory datasheet for its minimum operating frequency. May
be 83 or 125 MHz (I can't remember offhand); set by the internal DLL
delay length used to generate signal timings. 

It is possible to turn the DLL off (with a mode register setting) - that
may allow operation at lower speeds, but you're operating outside the
datasheet and you'd beon your own as far as timings go.

- Brian

Article: 136106
Subject: Re: ISE 9.2.03i problem
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 01 Nov 2008 02:21:44 +0000
Links: << >>  << T >>  << A >>
On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net>
wrote:

>On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:

>> But here's my worry: What if XST is actually right; and Quartus is one
>> step behind the pack in its optimisation technology (generating correct
>> but sub-optimal results)?
>>
>
>As always (and I'm assuming that Mark has already done this), you
>always run the simulator first to make sure that the design is
>functionally correct.  Optimization that changes the observable
>function is incorrect optimization.

OK, you're right. As long as the simulation test coverage is adequate, I
was spouting nonsense there. 

- Brian

Article: 136107
Subject: timing issue with ISE10 SP3
From: "Alessandro" <apoppi@email.it>
Date: Sat, 1 Nov 2008 18:05:34 +0100
Links: << >>  << T >>  << A >>
Hi all!

I have a working project with tight timing constraints which compiles 
successfully on ISE10.1 SP1.

This is the successful router phase:

Phase 1: 16814 unrouted;       REAL time: 23 secs
Phase 2: 15669 unrouted;       REAL time: 25 secs
Phase 3: 4742 unrouted;       REAL time: 33 secs
Phase 4: 4742 unrouted; (0)      REAL time: 33 secs
Phase 5: 4742 unrouted; (0)      REAL time: 35 secs
Phase 6: 4742 unrouted; (0)      REAL time: 36 secs
Phase 7: 0 unrouted; (0)      REAL time: 48 secs
Phase 8: 0 unrouted; (0)      REAL time: 51 secs
Phase 9: 0 unrouted; (0)      REAL time: 1 mins 6 secs

After installing the SP3, things goes worse. The timing score is a lot 
higher and the router issues the following warning:

Phase 1: 16795 unrouted;       REAL time: 14 secs
Phase 2: 15658 unrouted;       REAL time: 15 secs
Phase 3: 4800 unrouted;       REAL time: 20 secs
Phase 4: 4800 unrouted; (845062)      REAL time: 21 secs
Phase 5: 4846 unrouted; (783315)      REAL time: 23 secs
Phase 6: 4846 unrouted; (783315)      REAL time: 23 secs

WARNING:Route:441 - The router has detected a very high timing score 
(783315) for this design. It is extremely unlikely
   the router will be able to meet your timing requirements. To prevent 
excessive run time the router will change
   strategy. The router will now work to completely route this design but 
not to improve timing. This behavior will
   allow you to use the Static Timing Report and FPGA Editor to isolate the 
paths with timing problems. The cause of
   this behavior is either overly difficult constraints, or issues with the 
implementation or synthesis of logic in the
   critical timing path. If you would prefer the router continue trying to 
meet timing and you are willing to accept a
   long run time set the option "-xe c" to override the present behavior.

Phase 7: 0 unrouted; (783315)      REAL time: 28 secs
Phase 8: 0 unrouted; (837862)      REAL time: 31 secs
Phase 9: 0 unrouted; (836853)      REAL time: 42 secs

The problem is: I tried the -xe c option (it is the "continue on 
impossible"), the warning disappears but I get two failed timing constraints 
anyway. All the options are the same, timing driven place and route, 
optimization for speed, etc etc. I even tried to set the "design goal" to 
"timing performance", which sets even more options for timing care, with no 
success.

One of the suggestion of the timing wizard is to duplicate logic and prevent 
the tool from removing such duplication, but I don't know how to do it. 
Anyway, is there anybody else having such problems with SP3?

Thanks in advance
Alessandro



Article: 136108
Subject: Re: timing issue with ISE10 SP3
From: Gabor <gabor@alacron.com>
Date: Sat, 1 Nov 2008 13:00:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Nov 1, 12:05=A0pm, "Alessandro" <apo...@email.it> wrote:
> Hi all!
>
> I have a working project with tight timing constraints which compiles
> successfully on ISE10.1 SP1.
>
> This is the successful router phase:
>
> Phase 1: 16814 unrouted; =A0 =A0 =A0 REAL time: 23 secs
> Phase 2: 15669 unrouted; =A0 =A0 =A0 REAL time: 25 secs
> Phase 3: 4742 unrouted; =A0 =A0 =A0 REAL time: 33 secs
> Phase 4: 4742 unrouted; (0) =A0 =A0 =A0REAL time: 33 secs
> Phase 5: 4742 unrouted; (0) =A0 =A0 =A0REAL time: 35 secs
> Phase 6: 4742 unrouted; (0) =A0 =A0 =A0REAL time: 36 secs
> Phase 7: 0 unrouted; (0) =A0 =A0 =A0REAL time: 48 secs
> Phase 8: 0 unrouted; (0) =A0 =A0 =A0REAL time: 51 secs
> Phase 9: 0 unrouted; (0) =A0 =A0 =A0REAL time: 1 mins 6 secs
>
> After installing the SP3, things goes worse. The timing score is a lot
> higher and the router issues the following warning:
>
> Phase 1: 16795 unrouted; =A0 =A0 =A0 REAL time: 14 secs
> Phase 2: 15658 unrouted; =A0 =A0 =A0 REAL time: 15 secs
> Phase 3: 4800 unrouted; =A0 =A0 =A0 REAL time: 20 secs
> Phase 4: 4800 unrouted; (845062) =A0 =A0 =A0REAL time: 21 secs
> Phase 5: 4846 unrouted; (783315) =A0 =A0 =A0REAL time: 23 secs
> Phase 6: 4846 unrouted; (783315) =A0 =A0 =A0REAL time: 23 secs
>
> WARNING:Route:441 - The router has detected a very high timing score
> (783315) for this design. It is extremely unlikely
> =A0 =A0the router will be able to meet your timing requirements. To preve=
nt
> excessive run time the router will change
> =A0 =A0strategy. The router will now work to completely route this design=
 but
> not to improve timing. This behavior will
> =A0 =A0allow you to use the Static Timing Report and FPGA Editor to isola=
te the
> paths with timing problems. The cause of
> =A0 =A0this behavior is either overly difficult constraints, or issues wi=
th the
> implementation or synthesis of logic in the
> =A0 =A0critical timing path. If you would prefer the router continue tryi=
ng to
> meet timing and you are willing to accept a
> =A0 =A0long run time set the option "-xe c" to override the present behav=
ior.
>
> Phase 7: 0 unrouted; (783315) =A0 =A0 =A0REAL time: 28 secs
> Phase 8: 0 unrouted; (837862) =A0 =A0 =A0REAL time: 31 secs
> Phase 9: 0 unrouted; (836853) =A0 =A0 =A0REAL time: 42 secs
>
> The problem is: I tried the -xe c option (it is the "continue on
> impossible"), the warning disappears but I get two failed timing constrai=
nts
> anyway. All the options are the same, timing driven place and route,
> optimization for speed, etc etc. I even tried to set the "design goal" to
> "timing performance", which sets even more options for timing care, with =
no
> success.
>
> One of the suggestion of the timing wizard is to duplicate logic and prev=
ent
> the tool from removing such duplication, but I don't know how to do it.
> Anyway, is there anybody else having such problems with SP3?
>
> Thanks in advance
> Alessandro

Judging by the REAL time numbers in these reports, it looks like SP 3
isn't trying very hard, or that you have an extremely fast computer.
Look
at your settings for map and P&R.  Normally to get the best timing,
you need timing based packing and placement enabled in the Map
phase.  When this is enabled you can select a starting cost table
entry (default is 1) for both Map and P&R.  In this case the place &
route
cost table entry doesn't seem to matter as much as the Map
cost table entry.  This table entry is a seed for the initial
placement
and it allows you to start the recursive placement from different
starting points when you change it.  Often, especially when you have
little or no floorplanning, this can make a huge difference in your
final timing.

You could try running multi-pass place and route or just go through
a few table entries, one at a time manually.

By the way this problem may have nothing to do with SP3, but just
making the smallest change to the design can disrupt the initial
placement enough to cause what you see.

Floorplanning is generally the best way to fix these issues
permanently, but if the design builds quickly, you can use
the multi-pass place&route to let the tools do it for you.
When you get a placement that works well, you can use
guided placements for subsequent builds assuming your
design changes are small.

HTH,
Gabor

Article: 136109
Subject: Re: FPGA implementation of a PCI module
From: Mike Treseler <mtreseler@gmail.com>
Date: Sat, 01 Nov 2008 13:12:00 -0700
Links: << >>  << T >>  << A >>
axr0284 wrote:

> 1) If my module detects an address parity error but bit 8 in the
> command register used to turn on system error signaling is set to 0,
> does my system
> a) ignore the command
> b) Responds normally ignoring parity checking
> c) Takes possession of the request by asserting DEVSEL and then sends
> back a target abort.


I know very little about the PCI spec,
but it seems to me that a or b
would open the door to bugs that
would be difficult to track down.

  --Mike Treseler

Article: 136110
Subject: Re: timing issue with ISE10 SP3
From: "Alessandro" <apoppi@email.it>
Date: Sun, 2 Nov 2008 01:42:32 +0100
Links: << >>  << T >>  << A >>
Gabor wrote:

> Judging by the REAL time numbers in these reports, it looks like SP 3
> isn't trying very hard, or that you have an extremely fast computer.

First of all, thanks a lot for the useful information.
I think the first, since it is a P4 3.2GHz (not dualcore or whatsoever).

> phase.  When this is enabled you can select a starting cost table
> entry (default is 1) for both Map and P&R.  In this case the place &

Very interesting. I did activate the timing drive placement, but never 
modified that number. I will try to see how it improve the placement.

> You could try running multi-pass place and route or just go through
> a few table entries, one at a time manually.

If I got it right, increasing this number makes the tool work harder?

> By the way this problem may have nothing to do with SP3, but just
> making the smallest change to the design can disrupt the initial
> placement enough to cause what you see.

Absolutely right. For a long time I've had to deal with an extremely 
unstable design, then I've got a tip of adding  a BUFG over a clock line 
that was treated as a signal (it's generated by counters and comparators).

> Floorplanning is generally the best way to fix these issues
> permanently, but if the design builds quickly, you can use
> the multi-pass place&route to let the tools do it for you.

Not so quickly: it takes more than 10 minutes, so decided to learn about 
floorplanning. I've discovered several interesting things this afternoon. I 
finally understood what it meant when he said that the DCM and it's 
associated BUFG were not locked to good position, requiring a 
CLOCK_DEDICATED_ROUTE = FALSE constraint in order to proceed. By 
floorplanning I've been able to fix this, but here I have a question.

The project uses two DCM in a spartan 3E-500. There is a 50MHz clock pin fed 
into the first DCM, which generates 0/90/180 phase clock for a DDR 
controller. Then, the CLK0_OUT also goes to the input of the second DCM 
(configured as internal clock, so there is no IBUFG on the clock input) 
which synthesizes a 85MHz clock for other processes. The problem was due to 
the fact that this fpga has only 4 BUFG on top and 4 on bottom, so with 5 
outputs (0/90/180 on first DCM and CLK0/CLKFX on second) lead to the problem 
of having at least one BUFG on the opposite side of the chip.

I managed it by stopping using the CLK0_OUT from the second DCM so that I 
could place it far away without any problem. The reason for having two dcm 
is that I've added the ddr controller later, while the 85MHz output was 
already there. Do you think I may try to use a single dcm to generate any 
clock?

Also, BUFG are precious. I successfully tried to manually completely remove 
the CLK0_OUT signal from the second DCM, saving one BUFG. Now I have a neat 
placement with two dcm and four BUFG very close togheter. I've had to feed 
the dcm internal feedback with the CLK0_BUF (while before it was after the 
removed BUFG). Do you think that this may lead to problems? I would like to 
save the bufg because I will probably need it at a later stage.

> When you get a placement that works well, you can use
> guided placements for subsequent builds assuming your
> design changes are small.

I think you are several steps ahead on me about fpga :-)

Thanks!
Alessandro



Article: 136111
Subject: Re: timing issue with ISE10 SP3
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 02 Nov 2008 01:10:08 +0000
Links: << >>  << T >>  << A >>
On Sat, 1 Nov 2008 18:05:34 +0100, "Alessandro" <apoppi@email.it> wrote:

>Hi all!
>
>I have a working project with tight timing constraints which compiles 
>successfully on ISE10.1 SP1.

>After installing the SP3, things goes worse. The timing score is a lot 
>higher and the router issues the following warning:
>
>Phase 1: 16795 unrouted;       REAL time: 14 secs
>Phase 2: 15658 unrouted;       REAL time: 15 secs
>Phase 3: 4800 unrouted;       REAL time: 20 secs
>Phase 4: 4800 unrouted; (845062)      REAL time: 21 secs
>Phase 5: 4846 unrouted; (783315)      REAL time: 23 secs
>Phase 6: 4846 unrouted; (783315)      REAL time: 23 secs
>
>WARNING:Route:441 - The router has detected a very high timing score 
>(783315) for this design. It is extremely unlikely
>   the router will be able to meet your timing requirements. 

Look at the nature of the worst failing path.

I have just had a similar message porting a 7.1 era design to ISE10.
In my case, the signal paths looked about the same as before, but about
-2.3 ns of clock skew had crept in.

If this is the case for you, read on; otherwise ignore this post.

My clock enters via IBUFGDS (then an implicit BUFG) to the main logic,
and to some DCMs which generated related clocks in sync with the main
clock.

For some reason ISE10 (maybe just SP3) had started routing directly from
the IBUFGDS to the DCMs, but inserted a BUFG as before (and as it
should) in the clock to the main logic.

This advanced all my subsidiary clocks by just over 2 ns.
Which came as a bit of a surprise to me...

I resolved it by moving the IBUFGDS to the top level and manually
instantiating the following BUFG on the main clock signal. That gave XST
no excuse for feeding the DCMs from anything else...

- Brian

Article: 136112
Subject: Re: ISE 9.2.03i problem
From: "jtw" <wrightjt@hotmail.invalid>
Date: Sat, 1 Nov 2008 20:13:33 -0700
Links: << >>  << T >>  << A >>
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com...
> On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net>
> wrote:
>
>>On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com>
>>wrote:
>
>>> But here's my worry: What if XST is actually right; and Quartus is one
>>> step behind the pack in its optimisation technology (generating correct
>>> but sub-optimal results)?
>>>
>>
>>As always (and I'm assuming that Mark has already done this), you
>>always run the simulator first to make sure that the design is
>>functionally correct.  Optimization that changes the observable
>>function is incorrect optimization.
>
> OK, you're right. As long as the simulation test coverage is adequate, I
> was spouting nonsense there.
>
> - Brian

Just be aware that there are occasions where the simulation can be 
incorrect; just the other day, I was modifying a [non-clocked] process, but 
forgot to add a key signal to the sensitivity list.  So, simulation was 
'incorrect'--at least, undesired--and synthesis would have produced the 
desired behavior.  (In this case, it was in the test bench, so synthesis 
would have been immaterial.)

I found and corrected it quickly, and there is a compiler option to warn 
about synthesis mismatch, but still....  It is possible to have simulation 
wrong and synthesis correct, as well as vice-versa.

JTW 



Article: 136113
Subject: Re: ISE 9.2.03i problem
From: kennheinrich@sympatico.ca
Date: Sat, 1 Nov 2008 21:23:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Nov 1, 11:13=A0pm, "jtw" <wrigh...@hotmail.invalid> wrote:
> "Brian Drummond" <brian_drumm...@btconnect.com> wrote in message
>
> news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com...
>
>
>
> > On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjenni...@sbcglobal.net>
> > wrote:
>
> >>On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com>
> >>wrote:
>
> >>> But here's my worry: What if XST is actually right; and Quartus is on=
e
> >>> step behind the pack in its optimisation technology (generating corre=
ct
> >>> but sub-optimal results)?
>
> >>As always (and I'm assuming that Mark has already done this), you
> >>always run the simulator first to make sure that the design is
> >>functionally correct. =A0Optimization that changes the observable
> >>function is incorrect optimization.
>
> > OK, you're right. As long as the simulation test coverage is adequate, =
I
> > was spouting nonsense there.
>
> > - Brian
>
> Just be aware that there are occasions where the simulation can be
> incorrect; just the other day, I was modifying a [non-clocked] process, b=
ut
> forgot to add a key signal to the sensitivity list. =A0So, simulation was
> 'incorrect'--at least, undesired--and synthesis would have produced the
> desired behavior. =A0(In this case, it was in the test bench, so synthesi=
s
> would have been immaterial.)
>
> I found and corrected it quickly, and there is a compiler option to warn
> about synthesis mismatch, but still.... =A0It is possible to have simulat=
ion
> wrong and synthesis correct, as well as vice-versa.
>
> JTW

Two wrongs don't make a right. Wrong #1: describe the wrong logic
(according to well defined, intentioned language semantics) by
accidentally mis-typing the sensitivity list, then (wrong #2) claim
that the synthesis tool ought to be ignoring the semantics of the
language.  While this would certainly not be the first time this has
occurred (and I've probably been bitten by it, too), it's not really
accurate to say "simulation is incorrect".

 - Kenn

Article: 136114
Subject: Re: classic Spartan-3 DDR2 and IOBs
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 02 Nov 2008 09:04:21 GMT
Links: << >>  << T >>  << A >>
"Dan Kuechle" <danielgk@visi.com> wrote:

>
>"Eric" <jonas@mit.edu> wrote in message 
>news:bbf396a8-4678-461d-90b8-e29b26b165c7@v13g2000pro.googlegroups.com...
>>
>> Rob,
>>   This is fantastic help, esp. since I just got quotes on IBIS
>> simulators that exceed my
>> entire budget for this project. :) I'm shooting for somewhere between
>> 125 MHz and 150 MHz
>> for my clock, and plan on having a very simple, bursty interface.
>> I'm basically trying to clock this thing as slowly as I possibly can.
>> I am using a single DDR2
>> IC (16-bit wide) per interface which will be directly connected to the
>> FPGA as closely as possible.
>>
>> For the control signals, you recommend SSTL18_I_DCI on the FPGA side
>> and a pull-up
>> to VTT on the DDR2 side.
>>
>> You're then recommending using the SSTL_18_II IO standard for the DQ/
>> DQS signals on
>> the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just
>> using ODT on
>> the DDR2 side.
>>
>> If I understand correctly we can't use ODT for the address/control
>> signals on the DDR2 side
>> because DDR2 only supports ODT on data-related signals.

You won't need ODT because you can run the address/control signal at
half the memory frequency. You may even get away with LVCMOS signals
with lower drive strenghts to reduce power even more.

>> For your interface, did you use the Xilinx Memory Interface generator,
>> or do your own interface
>> by hand? MIG tries to place what seem like significant restrictions on
>> pin location, as well
>> as being a bit too general-purpose for our applications, but I'm
>> guessing if there
>> are pin constraints there's a reason for it.

Be aware that the MIG tool tries to get the maximum speed from the
FPGA for marketing purposes. If you roll your own interface and aim at
a lower frequency, the pin restrictions vanish and the complexity of
the interface is greatly reduced.

>Have you looked into running slower than 125 mhz (with the dll disabled)?  I 
>want to do this, at probably around 33mhz, but I'm having trouble getting 
>any information about it:  namely can I do it and will it work?  Just 
>wondering if you knew anything about that.

The datasheet specifies a minimum operating frequency. But whats the
use of DDR2 when using it at lower speeds? Perhaps DDR or SDRAM is a
better choice in such situations.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 136115
Subject: Re: ISE 9.2.03i problem
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 02 Nov 2008 13:55:03 +0000
Links: << >>  << T >>  << A >>
On Sat, 1 Nov 2008 20:13:33 -0700, "jtw" <wrightjt@hotmail.invalid>
wrote:

>"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
>news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com...
>> On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net>
>> wrote:
>>
>>>On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com>
>>>wrote:
>>
>>>> But here's my worry: What if XST is actually right; and Quartus is one
>>>> step behind the pack in its optimisation technology (generating correct
>>>> but sub-optimal results)?
>>>
>>>As always (and I'm assuming that Mark has already done this), you
>>>always run the simulator first to make sure that the design is
>>>functionally correct.  Optimization that changes the observable
>>>function is incorrect optimization.
>>
>> OK, you're right. As long as the simulation test coverage is adequate, I
>> was spouting nonsense there.

>Just be aware that there are occasions where the simulation can be 
>incorrect; just the other day, I was modifying a [non-clocked] process, but 
>forgot to add a key signal to the sensitivity list. 

That's a good example of what I meant by "inadequate" test coverage; the
simulator was accurately performing what you described; just not what
you meant to describe!

- Brian

Article: 136116
Subject: Re: PLBv4.6 with more than 16 slaves
From: Jeff Cunningham <jcc@sover.net>
Date: Sun, 02 Nov 2008 10:07:19 -0500
Links: << >>  << T >>  << A >>
MM wrote:
> Hi Ales,
> 
>> I have been using a DCR bus and I like it, but it will become obsolete
>> soon.
> 
> Could you please elaborate on what you know about DCR obsolescence?

I think this thread earlier this year may have started some rumors.

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/f902f659aab1fcc9/5199d4118b7b99e3?lnk=st&q=#5199d4118b7b99e3

I opened a webcase about DCR bus going away and was told DCR bus is 
still supported. Apparently some of the info in the thread was bogus or 
perhaps people were confusing microblaze support for DCR with support in 
the EDK and PPC.

PLB and DCR are both parts of the IBM coreconnect standard and serve 
complimentary functions. I think it would be sort of silly to have PLB 
without DCR.

-Jeff

Article: 136117
Subject: requesting solution for error:HDLParsers:810
From: subbu instru <gsreddyeee@gmail.com>
Date: Sun, 2 Nov 2008 08:00:30 -0800 (PST)
Links: << >>  << T >>  << A >>
i wrote a vhdl code for 8 bit adder, checked the syntax but there is
no syntax errors found. in the synthosis it is shoing synthe sis is
completed successfully but a warning simble is comming.
if want to simulate it shows error whih is bellow.

ERROR:HDLParsers:810 - "G:/subbu/model/addition/additest.vhw" Line
84. /= has two possible definitions in this scope.
Parsing "additest_beh.prj": 0.28


any body know the anser for this plese reply immediatly.


my code is:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;


---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity adder1 is
    Port ( clock : in  STD_LOGIC;
           reset : in  STD_LOGIC;
           A : in  STD_LOGIC_VECTOR (8 downto 0);
           B : in  STD_LOGIC_VECTOR (8 downto 0);
           SUM : out  STD_LOGIC_VECTOR (8 downto 0));
end adder1;

architecture Behavioral of adder1 is

begin
process(clock,reset)
  begin
  if (reset='0') then
    sum<="000000000";
	 elsif(clock'event and clock='1') then
    SUM <= A+B;
  end if;
  end process;

end Behavioral;


Article: 136118
Subject: Re: system verilog state machine
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Sun, 02 Nov 2008 13:23:35 -0600
Links: << >>  << T >>  << A >>
Even if I copy the example state machine from the Synplify help file that
gives the same message. There is something in the Synplify docs about not
supporting certain things in System Verilog at the moment so it could be
something to do with that. However they shouldnt be giving example code
that doesnt work.

Article: 136119
Subject: Re: timing issue with ISE10 SP3
From: "Alessandro" <apoppi@email.it>
Date: Sun, 2 Nov 2008 21:36:55 +0100
Links: << >>  << T >>  << A >>
Gabor wrote:

> Judging by the REAL time numbers in these reports, it looks like SP 3
> isn't trying very hard, or that you have an extremely fast computer.

...but I've selected several timing-related options, and if I choose the 
timing as "goal" (which sets even more options for this purpose) I get a 
worse result.

In the meantime I solved the problem I've had yesterday (SP3 also routes 
everything without timing issues) thanks to floorplan placement of the two 
DCM and related BUFG. Due to this improvement, however, I've been able to 
successfully increase the DDR speed from 50 to 85MHz (which an 
already-available clock in the design). Due to this, I went back to the 
problem: SP1 routes it, while SP3 gives three timing constraint problems.

Four clock signal have now a period constraint of 11ns instead of previous 
20 and this is the reason of the not-met constraints.

> you can select a starting cost table entry (default is 1) for both Map and 
> P&R.  In this case the place &
> route cost table entry doesn't seem to matter as much as the Map cost 
> table entry.  This table entry is a seed for the initial
> placement and it allows you to start the recursive placement from 
> different
> starting points when you change it.

This point is not so clear to me. I'm now trying the multipass place and 
route with 10 retries, leaving the cost table at 1. If change this number I 
will get different results?

> You could try running multi-pass place and route or just go through
> a few table entries, one at a time manually.

So if I change the cost table to, for example, 3 I get the same result I've 
got in retry number 3 when starting from table cost = 1?

> Floorplanning is generally the best way to fix these issues
> permanently, but if the design builds quickly, you can use
> the multi-pass place&route to let the tools do it for you.

Goood. I made floorplan for dcm and bufg, but floorplanning the signals 
seems too difficult to me

> When you get a placement that works well, you can use
> guided placements for subsequent builds assuming your
> design changes are small.

What is a guided placement? I can keep some of the previous good work 
locking it somehow?

Ciao!
Alessandro



Article: 136120
Subject: blockram init file in spartan 3E
From: "Alessandro" <apoppi@email.it>
Date: Sun, 2 Nov 2008 21:52:56 +0100
Links: << >>  << T >>  << A >>
Hi!

I'm using blockram which is initialized from a .coe file.

I need to often change the initialization data, and every time I have to go 
through the IP core manager and rebuild the component.

On my computer at home, furthermore, I'm unable to run the IP manager due to 
a lack of ram (512MB) which makes the stupid java machine unable to start.

Is there a way to update the blockram content directly? Browsing the source 
file, I found this line:
c_init_file_name => "mem_text.mif",
and opening the .mif file resulted in a clearly readable ascii file with 
binary rapresentation of data, for example "00011100".

Unfortunately, modifying this file does not change blockram content on next 
recompile, even after a cleanup of the project files.

Any hint?

Ciao and thanks in advance
Alessandro



Article: 136121
Subject: Re: FPGA implementation of a PCI module
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Sun, 2 Nov 2008 13:51:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On 1 Nov., 21:12, Mike Treseler <mtrese...@gmail.com> wrote:
> axr0284 wrote:
> > 1) If my module detects an address parity error but bit 8 in the
> > command register used to turn on system error signaling is set to 0,
> > does my system
> > a) ignore the command
> > b) Responds normally ignoring parity checking
> > c) Takes possession of the request by asserting DEVSEL and then sends
> > back a target abort.
>
> I know very little about the PCI spec,
> but it seems to me that a or b
> would open the door to bugs that
> would be difficult to track down.

But b) and c) can cause multiple targets to respond to the same cycle
because the address is corrupted, which might have been caused at the
receiver. I also don't have the spec handy during the weekend, but I
would choose a). A corrupted address should not not be treated as an
address match.

Kolja Sulimma

Article: 136122
Subject: Re: requesting solution for error:HDLParsers:810
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Mon, 03 Nov 2008 00:21:44 +0000
Links: << >>  << T >>  << A >>
On Sun, 2 Nov 2008 08:00:30 -0800 (PST), subbu instru
<gsreddyeee@gmail.com> wrote:

>ERROR:HDLParsers:810 - "G:/subbu/model/addition/additest.vhw" Line
>84. /= has two possible definitions in this scope.

It's telling you that...
>library IEEE;
>use IEEE.STD_LOGIC_1164.ALL;
>use ieee.std_logic_unsigned.all;
... there's one definition in here...
>use ieee.std_logic_arith.all;
... and another one in here...
>    SUM <= A+B;
... for the operand you use here.

The best solution is to delete BOTH those libraries; neither of them are
standards, and as you can see, they introduce confusing (and possibly
conflicting) definitions.

Then decide whether A, B and Sum are signed or unsigned.
Then use the appropriate type for them, from the ieee.numeric_std
library instead.

use ieee.numeric_std.all;
...  
           A : in  UNSIGNED (8 downto 0);
           B : in  UNSIGNED (8 downto 0);
           SUM : out  UNSIGNED (8 downto 0));
...
	SUM <= A+B;
...
And the design intent is clearer too.

- Brian

Article: 136123
Subject: 2D DCT algorithm
From: michaeldre@gmx.de (Michael Dreschmann)
Date: Mon, 03 Nov 2008 01:48:14 GMT
Links: << >>  << T >>  << A >>
Hi All,

I've written a JPEG encoder and inside the module I used the 2D DCT
from the Xilinx ISE 7.1 Coregenerator which works very good. Now we
want to use this encoder with a Virtex 5 FPGA which isn't supported by
den ISE 7.1 but unfortunately the Coregenerator from the ISE 9.1
doesn't support the 2D DCT any more. In the web I found a posting
telling that the 2D DCT isn't supported any more (why? ok I think I
learned that I only should use the Coregenerator for trivial things
like RAMs and FIFOs...) but there was a reference to xapp610 which
describes the implementation of an 2D DCT algorithm including sample
VHDL code. Unfortunately this code doesn't seem to work. It seems to
ignore the bit 7 of the 8 bit inputdata so no negative values are
possible and also the results for positive input data doesn't seem to
be correct. What I'm looking for is an agorithm written in VHDL (or if
that is not possible in Verilog) that performs the 2D DCT 8x8 points
with 8 bit signed input data and at least 12 bit signed output data.
Does anyone know of such a module or knows what's wrong with the
example from the xapp610?

Thanks very much for any suggestions.

Michael

Article: 136124
Subject: Re: requesting solution for error:HDLParsers:810
From: subbu instru <gsreddyeee@gmail.com>
Date: Sun, 2 Nov 2008 19:37:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 3, 5:21=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sun, 2 Nov 2008 08:00:30 -0800 (PST), subbu instru
>
> <gsreddy...@gmail.com> wrote:
> >ERROR:HDLParsers:810 - "G:/subbu/model/addition/additest.vhw" Line
> >84. /=3D has two possible definitions in this scope.
>
> It's telling you that...>library IEEE;
> >use IEEE.STD_LOGIC_1164.ALL;
> >use ieee.std_logic_unsigned.all;
>
> ... there's one definition in here...>use ieee.std_logic_arith.all;
>
> ... and another one in here...> =A0 =A0SUM <=3D A+B;
>
> ... for the operand you use here.
>
> The best solution is to delete BOTH those libraries; neither of them are
> standards, and as you can see, they introduce confusing (and possibly
> conflicting) definitions.
>
> Then decide whether A, B and Sum are signed or unsigned.
> Then use the appropriate type for them, from the ieee.numeric_std
> library instead.
>
> use ieee.numeric_std.all;
> ... =A0
> =A0 =A0 =A0 =A0 =A0 =A0A : in =A0UNSIGNED (8 downto 0);
> =A0 =A0 =A0 =A0 =A0 =A0B : in =A0UNSIGNED (8 downto 0);
> =A0 =A0 =A0 =A0 =A0 =A0SUM : out =A0UNSIGNED (8 downto 0));
> ...
> =A0 =A0 =A0 =A0 SUM <=3D A+B;
> ...
> And the design intent is clearer too.
>
> - Brian

hello brian,
thank u for given ur valid solution, but still iam getting same error.
plese help me with another good solution.



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