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 136075

Article: 136075
Subject: Re: Register File distributed all over the FPGA
From: Philipp <Patrick.Bateman23@gmx.at>
Date: Thu, 30 Oct 2008 12:04:54 +0000
Links: << >>  << T >>  << A >>
ease modify the constraint.
> 
> Does the little 2VP7 even have a SLICE_X100Y100? 
> Check the top corner coordinates in the floorplanner. 
> You may need a smaller range or a larger device.

Yes, I just checked it and it works now thanks ;)

INST "ARC_Ndp/Arc_Reg_File" AREA_GROUP = g1;
AREA_GROUP "g1" RANGE = SLICE_X0Y0:SLICE_X15Y79,SLICE_X16Y0:SLICE_X27Y79;

79 is the maximum!

Article: 136076
Subject: Re: Register File distributed all over the FPGA
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 30 Oct 2008 12:08:20 +0000
Links: << >>  << T >>  << A >>
On Thu, 30 Oct 2008 10:25:33 +0000, Philipp <Patrick.Bateman23@gmx.at>
wrote:

>Thanks for all the feedback guys, I really appreciate it. Anyway, in the 
>meantime at least I managed it to work that the translate stage accepts
>the ucf file which looks now as follows:
>
>INST "ARC_Ndp/Arc_Reg_File" AREA_GROUP = g1;
>AREA_GROUP "g1" RANGE = SLICE_X10Y10,SLICE_X100Y100;

>ERROR:MapHelpers:151 - Error while processing the area group range. 
>Unable to
>    create a LOC object using the constraint SLICE_X10Y10,SLICE_X100Y100 
>attached
>    to area group g1. One or more ranges contain syntax error or illegal 
>site.
>    Please modify the constraint.

Does the little 2VP7 even have a SLICE_X100Y100? 
Check the top corner coordinates in the floorplanner. 
You may need a smaller range or a larger device.

- Brian

Article: 136077
Subject: Xilinx RapidIO 5.1
From: Hans Dampf <bogus@nomail.bog>
Date: Thu, 30 Oct 2008 13:33:51 +0100
Links: << >>  << T >>  << A >>
Hi

I use the RapidIO cores provided by Xilinx for my diploma thesis. I 
have recently upgraded to version 5.1 and I just cannot get the 
simulation to work. Before September's IP Update, I patched my own 
application into the simulation provided by Xilinx for SRIO 4_4, and 
everything worked just fine.

With the new core, I can't even get the simple out of the box 
simulation to work.

Anybody around with similar problems and maybe a solution?

Any response is greatly appreciated!

Thanks,

H. Dampf


Article: 136078
Subject: Re: Xilinx RapidIO 5.1
From: Moritz Schmid <434128393>
Date: Thu, 30 Oct 2008 14:11:38 +0100
Links: << >>  << T >>  << A >>
On 2008-10-30 13:33:51 +0100, Hans Dampf <bogus@nomail.bog> said:

> Hi
> 
> I use the RapidIO cores provided by Xilinx for my diploma thesis. I 
> have recently upgraded to version 5.1 and I just cannot get the 
> simulation to work. Before September's IP Update, I patched my own 
> application into the simulation provided by Xilinx for SRIO 4_4, and 
> everything worked just fine.
> 
> With the new core, I can't even get the simple out of the box 
> simulation to work.
> 
> Anybody around with similar problems and maybe a solution?
> 
> Any response is greatly appreciated!
> 
> Thanks,
> 
> H. Dampf

Perhaps I should clarify what the problem is...
The problem with core 5.1 is that somehow, the transmitters don't get 
synchronized, so that the link won't become ready and the testbench 
times out..


Article: 136079
Subject: Re: ISE 9.2.03i problem
From: Duane Clark <user@domaininvalid.com>
Date: Thu, 30 Oct 2008 06:22:49 -0700
Links: << >>  << T >>  << A >>
Mark McDougall wrote:
> I've little experience with ISE & its idiosyncrasies, but I've since been
> told that this type of problem isn't uncommon. Apparently it's a little
> too aggressive with its optimisation where duplicate logic is removed...

Not sure who told you that, but I do that sort of thing all the time 
with variables in ISE 9.2, and have never had a bit of trouble. If you 
want to see a program that is extremely aggressive about finding and 
removing duplicate logic, try out Synplify sometime. But removing 
duplicate logic is a good thing, not bad.

About the only difference in the way I code things is that I always put 
the clock enable within the clocked part of the process, and never in 
the sensitivity list (a clock enable should not be put there anyway).

Article: 136080
Subject: Re: ISE 9.2.03i problem
From: Dave <dhschetz@gmail.com>
Date: Thu, 30 Oct 2008 07:59:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
> process (reset, clk, clk_ena)
> =A0 variable hactive_v_r =A0: std_logic_vector(3 downto 0) :=3D (others =
=3D> '0');
> begin
> =A0 if reset =3D '1' then
> =A0 =A0 hactive_v_r :=3D (others =3D> '0');
> =A0 elsif rising_edge(clk) and clk_ena =3D '1' then
> =A0 =A0 ...
> =A0 =A0 hactive_v_r :=3D hactive_v_r(hactive_v_r'left-1 downto 0) & hacti=
ve_s;
> =A0 end if;
> end process;
>
> BTW 'h_active_s' is a signal declared in the containing entity, and is
> definitely not optimised out.
>
> However, when building the project for Xilix under ISE 9.2.03i, I get the
> following warnings during synthesis:
>
> WARNING:Xst:653 - Signal <hactive_v_r<3>> is used but never assigned. Tie=
d
> to value 0.
> WARNING:Xst:1780 - Signal <hactive_v_r<2:0>> is never used or assigned.
>

Could it be that you have a signal declared which has the same name as
the variable? Does anyone know if XST still warns that a signal is
being removed, even if it's actually a variable?

If there were a signal by the same name which is being optimized away,
maybe XST gets confused and gets rid of both.

Dave

Article: 136081
Subject: Polmaddie1 - For Traffic Lights Junkies
From: John Adair <g1@enterpoint.co.uk>
Date: Thu, 30 Oct 2008 09:33:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
As promised another new product Polmaddie1 http://www.enterpoint.co.uk/cpld=
_boards/polmaddie1.html.
It's a very simple CPLD board based on Coolrunner-II. It's aimed at
doing student or hobby learning with 4 sets of traffic lights to drive
and you can even get your PC involved via the serial port providing
FTDI FT232RQ chip that's on board. You can write custom software to
drive this serial port or simply send charactors from a terminal
emulator like Hyperterminal to drive sequences.

We also made this project integration friendly with the main headers
on a 0.1inch or 2.54mm grid so strip-board is a possible carrier of
add-on electronics. The main headers will support up to 60 I/O between
them and 3.3V and GND are there to support things hanging off on
ribbon cables etc..

Pricing isn't 100% finalised but for lab quantities it will be around
GBP=A320 - US$34, 26=80 on current exchange rates.

As always let me know what you guys think of the product and what else
you might like in this new product range.

John Adair
Enterpoint Ltd. - Providing VHDL and Verilog Training Platforms.

Article: 136082
Subject: Re: Polmaddie1 - For Traffic Lights Junkies
From: Gabor <gabor@alacron.com>
Date: Thu, 30 Oct 2008 12:27:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 11:33=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> As promised another new product Polmaddie1http://www.enterpoint.co.uk/cpl=
d_boards/polmaddie1.html.
> It's a very simple CPLD board based on Coolrunner-II. It's aimed at
> doing student or hobby learning with 4 sets of traffic lights to drive
> and you can even get your PC involved via the serial port providing
> FTDI FT232RQ chip that's on board. You can write custom software to
> drive this serial port or simply send charactors from a terminal
> emulator like Hyperterminal to drive sequences.
>
> We also made this project integration friendly with the main headers
> on a 0.1inch or 2.54mm grid so strip-board is a possible carrier of
> add-on electronics. The main headers will support up to 60 I/O between
> them and 3.3V and GND are there to support things hanging off on
> ribbon cables etc..
>
> Pricing isn't 100% finalised but for lab quantities it will be around
> GBP=A320 - US$34, 26=80 on current exchange rates.
>
> As always let me know what you guys think of the product and what else
> you might like in this new product range.
>
> John Adair
> Enterpoint Ltd. - Providing VHDL and Verilog Training Platforms.

Very cute :)

Just need to remote the traffic lights for the model RR junkies.

14.318 MHz sounds like a video frequency, not optimum for the
UART baud rate, but high enough to get within 1% for the common
rates.  Was this frequency chosen based on price?

Regards,
Gabor

Article: 136083
Subject: Re: Possibility of Driving FPGA clock from an other FPGA ?
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 30 Oct 2008 17:00:03 -0400
Links: << >>  << T >>  << A >>
It is not clear if you are talking about an existing piece of hardware or a 
board to be designed. Generally speaking it shouldn't be a problem, but you 
need to have right connections on right pins using right type of traces on 
the board.

/Mikhail



"Moazzam" <moazzamhussain@gmail.com> wrote in message 
news:186ebd57-d1f7-4440-a869-78fe4f5aeb37@a70g2000hsh.googlegroups.com...
> Hi,
>
> In one of my project, I am using two FPGAs on a custom board. The
> first one is Xilinx Virtex-2 Pro XC2VP20 and the other one is
> Spartan-3 (XC3S400). Virtex-2 Pro FPGA is driven by a clock of 32MHz
> while Spartan-3 FPGA is driven by 19.6608MHz.
>
> A trivial approach to establish inter connectivity between the FPGAs
> working in different clock domains is through a FIFO. (Just a
> thought), I need to know if it is possible to provide 199.6608 MHz
> clock to Virtex-2 Pro FPGA as an output from Spartan-3 FPGA. Both the
> FPGA lie within 1.5 inches on multilayered board and whether the
> current requirement of input clock can be met from the output of FPGA
> pin ?
>
>
> Regards
> /MH 



Article: 136084
Subject: Re: Polmaddie1 - For Traffic Lights Junkies
From: John Adair <g1@enterpoint.co.uk>
Date: Thu, 30 Oct 2008 15:01:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
The oscillator in the photo is in a socket so can be changed to
whatever anyone wants to have. We already carry a wide range of these
oscillators so supplying options isn't a problem. It's not fully
decided if we will ship oscillators with the board as the FTDI chip
can also output 6/12/24/48 MHz when reprogrammed from it's default
state and we have wired that in. Once we have confirmed this
functionality we will decide if to ship an oscillator or to leave as a
clear socket.

John Adair
Enterpoint Ltd.

On 30 Oct, 19:27, Gabor <ga...@alacron.com> wrote:
> On Oct 30, 11:33=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
>
>
>
>
> > As promised another new product Polmaddie1http://www.enterpoint.co.uk/c=
pld_boards/polmaddie1.html.
> > It's a very simple CPLD board based on Coolrunner-II. It's aimed at
> > doing student or hobby learning with 4 sets of traffic lights to drive
> > and you can even get your PC involved via the serial port providing
> > FTDI FT232RQ chip that's on board. You can write custom software to
> > drive this serial port or simply send charactors from a terminal
> > emulator like Hyperterminal to drive sequences.
>
> > We also made this project integration friendly with the main headers
> > on a 0.1inch or 2.54mm grid so strip-board is a possible carrier of
> > add-on electronics. The main headers will support up to 60 I/O between
> > them and 3.3V and GND are there to support things hanging off on
> > ribbon cables etc..
>
> > Pricing isn't 100% finalised but for lab quantities it will be around
> > GBP=A320 - US$34, 26=80 on current exchange rates.
>
> > As always let me know what you guys think of the product and what else
> > you might like in this new product range.
>
> > John Adair
> > Enterpoint Ltd. - Providing VHDL and Verilog Training Platforms.
>
> Very cute :)
>
> Just need to remote the traffic lights for the model RR junkies.
>
> 14.318 MHz sounds like a video frequency, not optimum for the
> UART baud rate, but high enough to get within 1% for the common
> rates. =A0Was this frequency chosen based on price?
>
> Regards,
> Gabor- Hide quoted text -
>
> - Show quoted text -


Article: 136085
Subject: Re: Downsizing Verilog synthesization.
From: gavin@allegro.com (Gavin Scott)
Date: Thu, 30 Oct 2008 17:43:33 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> My thought was stepper motors on each tuning peg.  (Small and
> geared down a lot.)

Gibson makes a robotic self-tuning guitar that works this way I believe.

G.

Article: 136086
Subject: Re: ISE 9.2.03i problem
From: kennheinrich@sympatico.ca
Date: Thu, 30 Oct 2008 16:53:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 29, 7:35=A0pm, Mark McDougall <ma...@vl.com.au> wrote:
> I've little experience with ISE & its idiosyncrasies, but I've since been
> told that this type of problem isn't uncommon. Apparently it's a little
> too aggressive with its optimisation where duplicate logic is removed...
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266

I would also expect this to create flops, exactly as you seem to want.
Without the full details of the rest of your code, I took an educated
guess and made up some logic (foo). I tried out the following design
in ISE 9.1.02i and it created some nontrivial logic for hactive_v_r(3
downto 0), after synthesis (only, into the default xcv5vlx50 device)
and a glance at the RTL viewer.

Two other tangential thoughts crossed my mind as well:

(1) why do you have clk_ena in the sensitivity list? Here in the
Castle Anthrax there's only one punishment for random, desparate-
looking sensitivity lists :-)

(2) the question has often arisen here, as to why std_logic_arith and
std_logic_unsigned keep rearing their ugly heads in otherwise well-
intentioned code. One answer appeared when I (despite my better
instincts, and due to sheer laziness) used that damn-fool Xilinx
design entry wizard to create the top level shown below.  "If Xilinx
does it, it must be right!", right?

Cheers, new Bruce.

 - Kenn

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity fidget is
    Port ( reset : in  STD_LOGIC;
           clk : in  STD_LOGIC;
           clk_ena : in  STD_LOGIC;
           hactive_input : in  STD_LOGIC;
           foo_output : out  STD_LOGIC);
end fidget;

architecture Behavioral of fidget is
  signal foo : std_logic;
  signal hactive_s : std_logic;
begin
  hactive_s <=3D hactive_input;
  foo_output <=3D foo;

  process (reset, clk, clk_ena)
    variable hactive_v_r  : std_logic_vector(3 downto 0) :=3D (others =3D>
'0');
  begin
    if reset =3D '1' then
      hactive_v_r :=3D (others =3D> '0');
    elsif rising_edge(clk) and clk_ena =3D '1' then
	   if hactive_v_r =3D "0000" then
		    foo <=3D not foo;
		end if;

      hactive_v_r :=3D hactive_v_r(hactive_v_r'left-1 downto 0) &
hactive_s;
    end if;
  end process;

end Behavioral;


Article: 136087
Subject: Re: ISE 9.2.03i problem
From: Mark McDougall <markm@vl.com.au>
Date: Fri, 31 Oct 2008 11:26:32 +1100
Links: << >>  << T >>  << A >>
Duane Clark wrote:

> But removing
> duplicate logic is a good thing, not bad.

Agreed, but I've been told that the problem lies with duplicate logic and
further optimisation that reveals that *one* of the "duplicated" logic
blocks turns out to be ultimately unused - the optimiser then removes the
"duplicated" logic and the *other* block, which *is* required, gets lost...

Not speaking from and ISE experience myself, I'd guess that the order of
optimisations gets a little screwed... or at least side effects aren't
properly analysed.

In any case, I'm assured that turning *OFF* all optimisations results in
correctly-functioning code.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 136088
Subject: Re: ISE 9.2.03i problem
From: Mark McDougall <markm@vl.com.au>
Date: Fri, 31 Oct 2008 11:36:05 +1100
Links: << >>  << T >>  << A >>
kennheinrich@sympatico.ca wrote:

> Without the full details of the rest of your code, I took an educated
> guess and made up some logic (foo). I tried out the following design
> in ISE 9.1.02i and it created some nontrivial logic for hactive_v_r(3
> downto 0), after synthesis (only, into the default xcv5vlx50 device)
> and a glance at the RTL viewer.

I suspect that the problem requires more of my code to be included - the
process itself is rather larger than my snippet in the posting...

Try as I might, I can't see anything wrong with it myself, and the fact
that (1) changing to signals works and (2) quartus works (with the
original code) I still cling to my belief that it's an ISE bug...

> (1) why do you have clk_ena in the sensitivity list? Here in the
> Castle Anthrax there's only one punishment for random, desparate-
> looking sensitivity lists :-)

Noted! I probably picked up that habit long ago when first starting out
and never gave it a second thought... you've just made a difference to
someone - take the rest of the day off! :)

> (2) the question has often arisen here, as to why std_logic_arith and
> std_logic_unsigned keep rearing their ugly heads in otherwise well-
> intentioned code. One answer appeared when I (despite my better
> instincts, and due to sheer laziness) used that damn-fool Xilinx
> design entry wizard to create the top level shown below.  "If Xilinx
> does it, it must be right!", right?

Coincidently, I've just spent a few days going through my entire code base
and removing all references to std_logic_arith. The most painful by far
was my copious use of EXT(), which is now replaced with a much more
cumbersome and less-flexible use of RESIZE(). :( It's something I've been
putting off but every time I read a post on the subject I felt another
pang of guilt! ;)

Thanks for your comments!

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 136089
Subject: Re: ISE 9.2.03i problem
From: Mark McDougall <markm@vl.com.au>
Date: Fri, 31 Oct 2008 12:06:01 +1100
Links: << >>  << T >>  << A >>
Dave wrote:

> Could it be that you have a signal declared which has the same name as
> the variable? 

No, sorry.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 136090
Subject: Re: ISE 9.2.03i problem
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 30 Oct 2008 21:47:05 -0400
Links: << >>  << T >>  << A >>

"Mark McDougall" <markm@vl.com.au> wrote in message 
news:490a52fa$1@dnews.tpgi.com.au...
> kennheinrich@sympatico.ca wrote:
>
> Try as I might, I can't see anything wrong with it myself, and the fact
> that (1) changing to signals works and (2) quartus works (with the
> original code) I still cling to my belief that it's an ISE bug...
>

You've submitted this as a bug to the good folks at Xilinx, correct?  It 
doesn't help you with the tool this time around, but eventually it gets 
fixed (if the submitters persist) or you move on to other tools, other 
suppliers.

KJ 



Article: 136091
Subject: Re: Xilinx RapidIO 5.1
From: "jtw" <wrightjt@hotmail.invalid>
Date: Thu, 30 Oct 2008 20:37:29 -0700
Links: << >>  << T >>  << A >>
I haven't used those cores, but I know there were issues with some Rocket IO 
cores and Modelsim, older versions.  Do you get any 'unbound' messages, or 
stuff like that?

JTW
"Moritz Schmid" <434128393> wrote in message 
news:2008103014113875249-434128393@news-europe.giganews.com...
> On 2008-10-30 13:33:51 +0100, Hans Dampf <bogus@nomail.bog> said:
>
>> Hi
>>
>> I use the RapidIO cores provided by Xilinx for my diploma thesis. I have 
>> recently upgraded to version 5.1 and I just cannot get the simulation to 
>> work. Before September's IP Update, I patched my own application into the 
>> simulation provided by Xilinx for SRIO 4_4, and everything worked just 
>> fine.
>>
>> With the new core, I can't even get the simple out of the box simulation 
>> to work.
>>
>> Anybody around with similar problems and maybe a solution?
>>
>> Any response is greatly appreciated!
>>
>> Thanks,
>>
>> H. Dampf
>
> Perhaps I should clarify what the problem is...
> The problem with core 5.1 is that somehow, the transmitters don't get 
> synchronized, so that the link won't become ready and the testbench times 
> out..
> 



Article: 136092
Subject: Re: Xilinx RapidIO 5.1
From: Hans Dampf <bogus@nomail.bog>
Date: Fri, 31 Oct 2008 06:41:09 +0100
Links: << >>  << T >>  << A >>
Hi,

no there were no such problems. It's straight, flawless compilation and 
optimization.

Anyway, I don't have to upgrade to the new cores. I just thought it 
would be nice, because Xilinx has fixed some problems of the old core, 
of which I am sure, I will run right into, when least expected...

hans

On 2008-10-31 04:37:29 +0100, "jtw" <wrightjt@hotmail.invalid> said:

> I haven't used those cores, but I know there were issues with some Rocket IO
> cores and Modelsim, older versions.  Do you get any 'unbound' messages, or
> stuff like that?
> 
> JTW
> "Moritz Schmid" <434128393> wrote in message
> news:2008103014113875249-434128393@news-europe.giganews.com...
>> On 2008-10-30 13:33:51 +0100, Hans Dampf <bogus@nomail.bog> said:
>> 
>>> Hi
>>> 
>>> I use the RapidIO cores provided by Xilinx for my diploma thesis. I have
>>> recently upgraded to version 5.1 and I just cannot get the simulation to
>>> work. Before September's IP Update, I patched my own application into the
>>> simulation provided by Xilinx for SRIO 4_4, and everything worked just
>>> fine.
>>> 
>>> With the new core, I can't even get the simple out of the box simulation
>>> to work.
>>> 
>>> Anybody around with similar problems and maybe a solution?
>>> 
>>> Any response is greatly appreciated!
>>> 
>>> Thanks,
>>> 
>>> H. Dampf
>> 
>> Perhaps I should clarify what the problem is...
>> The problem with core 5.1 is that somehow, the transmitters don't get
>> synchronized, so that the link won't become ready and the testbench times
>> out..



Article: 136093
Subject: FPGA implementation of a PCI module
From: axr0284 <axr0284@yahoo.com>
Date: Fri, 31 Oct 2008 05:58:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
 I am trying to build a simple PCI communication module. I am stuck
with the error response due to an address parity error. I was
wondering if someone had worked on something like this, they would
probably know the answer.

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.
The PCI spec is not too clear about this particular case.
Thanks for the help.
Amish

Article: 136094
Subject: Re: ISE 9.2.03i problem
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 31 Oct 2008 13:54:58 +0000
Links: << >>  << T >>  << A >>
On Fri, 31 Oct 2008 11:26:32 +1100, Mark McDougall <markm@vl.com.au>
wrote:

>Duane Clark wrote:
>
>> But removing
>> duplicate logic is a good thing, not bad.

Usually...

One case where removing duplicate logic IS harmful: when a registered
signal is used internally, and also presented on output pins. XST will
try to share the register, while you want to duplicate it to push
registers into the output blocks for better I/O timing.

You can turn "equivalent-register-removal" off globally with a flag, or
for individual signals by attaching an attribute. Or you can "keep"
signals which would otherwise be optimised away, with a "keep" atribute.
Use sparingly; they will probably be harmlessly ignored by other tools,
but don't really help portability.

>Agreed, but I've been told that the problem lies with duplicate logic and
>further optimisation that reveals that *one* of the "duplicated" logic
>blocks turns out to be ultimately unused - the optimiser then removes the
>"duplicated" logic and the *other* block, which *is* required, gets lost...

If the other block really was required (as in, it was connected to an
output or other logic (crucially; other logic which cannot itself be
deleted!) it would have been kept.

Though I have flamed XST , it is actually quite difficult to catch it
out in real synthesis bugs and I don't believe you have here. (The one
time I caught it creating incorrect logic, it got variables right, but
not signals, when signals were modified within a procedure. In-lining
the procedure calls in the main process gave correct results. Xilinx
have acknowledged this bug and a change request has been filed. They
really do want it to work right!)

I suspect something obscure in the logic you didn't post is causing it
to be simplified; therefore the other block appears redundant.

>In any case, I'm assured that turning *OFF* all optimisations results in
>correctly-functioning code.

This may be expedient, but feels like glossing over the problem, which
can re-appear later when something else changes.

It may be worth simplifying the failing case to post here.

Either you will see the problem in the process; or someone here may see
it. Or, if you really have caught XST out, then you have a test case to
attach to a Webcase reporting the bug.

- Brian


Article: 136095
Subject: Re: ISE 9.2.03i problem
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 31 Oct 2008 14:00:59 +0000
Links: << >>  << T >>  << A >>
On Fri, 31 Oct 2008 11:36:05 +1100, Mark McDougall <markm@vl.com.au>
wrote:

>Try as I might, I can't see anything wrong with it myself, and the fact
>that (1) changing to signals works and (2) quartus works (with the
>original code) I still cling to my belief that it's an ISE bug...

(Note: I haven't used Quartus; I may be doing it an injustice here)

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)? 

And the next revision of Quartus improves its optimisation algorithms...

- Brian


Article: 136096
Subject: Re: classic Spartan-3 DDR2 and IOBs
From: Eric <jonas@mit.edu>
Date: Fri, 31 Oct 2008 07:02:37 -0700 (PDT)
Links: << >>  << T >>  << A >>

> Hi Eric,
>
> This is indeed a tricky area. I've implemented an S3 talking to DDR2
> components myself, and termination gave us loads of headaches.
> First of all, what frequency are you trying to run at? I assume it's
> somewhere around 133MHz, which is pretty slow by DDR2 standards and
> you therefore you can ignore all of the dire warnings you see in
> datasheets about correct termination being mandatory (assuming your
> trace lengths aren't too long).
>
> DCI is a power-hog, but only when you use standards that have parallel
> termination. In this case the DCI comprise a "Thevenin equivalent"
> 200R accross the 1V8 supply for each IOB which can add up to a lot of
> power dissipation. For series termination such as SSTL18_I_DCI the
> series resistor adds little to the power consumption.
> Therefore, for address and control signals I would recommend you use
> SSTL18_I_DCI at the FPGA and termination to Vtt at the memory end. You
> could probably also just use SSTL18_I at these speeds without any
> problems.
>
> For the DQ/DQS signals I would use SSTL_18_II with an external 50R to
> Vtt at the FPGA end, this needs to be fairly close to the FPGA pin,
> but again at these frequencies it isn't that critical. At the memory
> end use the ODT feature and save yourselves loads of termination
> resistors.
>
> HTH,
> Rob

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


Article: 136097
Subject: Re: ISE 9.2.03i problem
From: kennheinrich@sympatico.ca
Date: Fri, 31 Oct 2008 07:42:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 9:47=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Mark McDougall" <ma...@vl.com.au> wrote in message
>
> news:490a52fa$1@dnews.tpgi.com.au...
>
> > kennheinr...@sympatico.ca wrote:
>
> > Try as I might, I can't see anything wrong with it myself, and the fact
> > that (1) changing to signals works and (2) quartus works (with the
> > original code) I still cling to my belief that it's an ISE bug...
>
> You've submitted this as a bug to the good folks at Xilinx, correct? =A0I=
t
> doesn't help you with the tool this time around, but eventually it gets
> fixed (if the submitters persist) or you move on to other tools, other
> suppliers.
>
> KJ

I think there might be a mis-attribution here: it was Mark, not I, who
clings to his belief.

But more topically, Brian Drummond suggested in another post that
there could be other stuff happening in other logic that causes the
optimization to occur. If the code can be simplified to the point
where it can be posted here and still show the bug, I will be happy to
try it out on my version of ISE (and if motivated, even try out
another synthesizer). If there's a real tool bug lurking here, let's
kick it back the the vendor.

 - Kenn

Article: 136098
Subject: Re: ISE 9.2.03i problem
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 31 Oct 2008 08:06:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 31, 10:00=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Fri, 31 Oct 2008 11:36:05 +1100, Mark McDougall <ma...@vl.com.au>
> wrote:
>
> >Try as I might, I can't see anything wrong with it myself, and the fact
> >that (1) changing to signals works and (2) quartus works (with the
> >original code) I still cling to my belief that it's an ISE bug...
>
> (Note: I haven't used Quartus; I may be doing it an injustice here)
>
> 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.

Kevin Jennings

Article: 136099
Subject: Re: PLBv4.6 with more than 16 slaves
From: ales.gorkic@gmail.com
Date: Fri, 31 Oct 2008 09:44:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
HI Mikhail,

Most of my slaves are custom built.
I have been using a DCR bus and I like it, but it will become obsolete
soon.
Multiple PLBs connected to MPMC? Not a good idea If one Microblaze
want to address all slaves. As far as I know MPMC bus bridging was
removed from the core.
Since I need to add more slaves I think I will add another Microblaze,
another PLB and a PLB-PLB bridge.
I have tons of free logic resources and a need some extra processing
power.

Thank you for the suggestions.

Cheers,

Ales

On Oct 29, 9:02 pm, "MM" <mb...@yahoo.com> wrote:
> Ales,
>
> I agree with Brian that it is not a good idea to try to modify the PLB bus
> core. Even if you succeed now you will have problems down the road when you
> decide that you need to upgrade the design to the next version .
>
> What are your slaves? Are any of them custom? Do they even have to be on PLB
> bus? Consider DCR for slower peripherals that just a few registers. Also,
> take a look at MPMC core, it allows to have multiple PLB busses and it might
> be a better idea in some cases than a PLB-to-PLB bridge...
>
> /Mikhail
>
> <ales.gor...@gmail.com> wrote in message
>
> news:bf07a0b5-5429-44d5-bbd9-1366eac8fb21@t41g2000hsc.googlegroups.com...
>
> > Hi all,
>
> > I have encountered a problem where I least expected.
> > I am using EDK 10.1.03 and I have build a system with 17 slaves on a
> > PLBv4.6 bus.
> > Well, the plb wrapper XPS reported an error:
> > something like C_NUM_SLAVES =  17  is out of range [0:16]
>
> > What should I do?
> > Use a bridge and add another PLB or copy plb_v46 core to local dir and
> > expand the range to 17?
>
> > Cheers,
>
> > Ales




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