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 123025

Article: 123025
Subject: Re: Xilinx Spartan FPGA : Strange Errors
From: ghelbig@lycos.com
Date: Tue, 14 Aug 2007 11:32:07 -0700
Links: << >>  << T >>  << A >>
On Aug 14, 10:24 am, moo...@yahoo.co.uk wrote:
> Hi,
>
> I wonder if anyone has seen something like this.
>
> I have an FPGA design targeted at an Spartan xc3s1500 and using
> ISE8.2.
>
> We are using a spartan evaluation board with some 7 segment LED's.
>
> If I make minor changes to the pinout, sometimes the FPGA stops
> functioning completely. What is interesting, is that the 7 segment
> LED's are not driven. The VHDL code for this is :
>
>   p_seven_seg : process(clk system_reset_n,)
>
>   begin
>     if(system_reset_n = '0')then
>       seven_seg_1 <= "1111111";
>     elsif(clk = '1'and clkt'event) then
>       case (conv_integer(p1)) is
>         when 0      =>
>           seven_seg_1 <= not("0111111");
>         when others =>
>           seven_seg_1 <= "1111111";
>       end case;

My guess is that you're downloading the bitstream, watching it work,
making a small change, downloading it again, etc., etc.

There are situations where the second (and subsequent) bit stream
loads just don't work.  This depends mostly on your programming method
and hardware.

Try removing the power from the FPGA completely before doing bitstream
loads.

G.


Article: 123026
Subject: Re: Xilinx Spartan FPGA : Strange Errors
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 14 Aug 2007 19:34:07 +0100
Links: << >>  << T >>  << A >>
<moogyd@yahoo.co.uk> wrote in message 
news:1187112403.482357.230890@d55g2000hsg.googlegroups.com...
>
> We are using a spartan evaluation board with some 7 segment LED's.
>
> If I make minor changes to the pinout, sometimes the FPGA stops
> functioning completely. What is interesting, is that the 7 segment
> LED's are not driven.
>
>
> Steven
>
Hi Steven,
Your VHDL is missing an 'end if' I think, and you should use numeric.std, 
it's much nicer.

Have you 'loc'ked all the pins in your design? Does your design meet the 
timing?

HTH., Syms. 



Article: 123027
Subject: SDRAM Controller
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Tue, 14 Aug 2007 13:50:23 -0500
Links: << >>  << T >>  << A >>

Hi

I have designed an SDRAM controller and nearly ready to synth and P&R. My
question is do I need to add any offset constraints to the ucf? I see that
the Xilinx XAPP134 uses them but the newer DDR designs which are generated
using MIG do not. Any info would be appreciated?

Cheers

Jon

Article: 123028
Subject: Delaying a pulse train
From: m <martin.usenet@gmail.com>
Date: Tue, 14 Aug 2007 18:52:39 -0000
Links: << >>  << T >>  << A >>
I have to delay a pulse train by a given number of clocks on the same
domain as the pulse to be delayed.

The best approach I can think of is to run a counter of sufficient
width and log pulse transitions and states into a circular "pulse
transition list" of sufficient depth.  After waiting for the desired
number of clock transitions (the delay) an output counter of the same
width as the input sample counter is allowed to start counting.  This
counter is used to address the "pulse transition list" to generate a
delayed output that matches the input.

Using SelectRAM memory for delay is out of the question as too much
memory would be required and it is needed elsewhere in the design.


Can anyone suggest a better way to do this?  The incoming pulses are
relatively regular and can be of any duration, from a few clocks to
hundreds.

Thanks,

-Martin


Article: 123029
Subject: Re: Delaying a pulse train
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 14 Aug 2007 12:01:33 -0700
Links: << >>  << T >>  << A >>
Martin, have you thought of using the dual-ported BlockRAMs?
Use a free-running counter to address one port, where you write the
incoming data.
Use another counter, appropriately offset, (or a subtractor) to read
the data out on the other port.

As long as the delay is shorter than the BRAM depth, this process can
go on forever...
Peter Alfke
==============

On Aug 14, 11:52 am, m <martin.use...@gmail.com> wrote:
> I have to delay a pulse train by a given number of clocks on the same
> domain as the pulse to be delayed.
>
> The best approach I can think of is to run a counter of sufficient
> width and log pulse transitions and states into a circular "pulse
> transition list" of sufficient depth.  After waiting for the desired
> number of clock transitions (the delay) an output counter of the same
> width as the input sample counter is allowed to start counting.  This
> counter is used to address the "pulse transition list" to generate a
> delayed output that matches the input.
>
> Using SelectRAM memory for delay is out of the question as too much
> memory would be required and it is needed elsewhere in the design.
>
> Can anyone suggest a better way to do this?  The incoming pulses are
> relatively regular and can be of any duration, from a few clocks to
> hundreds.
>
> Thanks,
>
> -Martin



Article: 123030
Subject: Re: Delaying a pulse train
From: m <martin.usenet@gmail.com>
Date: Tue, 14 Aug 2007 19:10:04 -0000
Links: << >>  << T >>  << A >>
> Martin, have you thought of using the dual-ported BlockRAMs?

It would consume too many BRAMs.  I need delays in the order of 500us
at 150MHz.  That's about 5 BRAMs (Virtex2).  I need them for other
portions of the design.

It'd sure be easy though!

-M



Article: 123031
Subject: Re: Xilinx Spartan FPGA : Strange Errors
From: Dave Pollum <vze24h5m@verizon.net>
Date: Tue, 14 Aug 2007 12:16:10 -0700
Links: << >>  << T >>  << A >>
On Aug 14, 12:24 pm, moo...@yahoo.co.uk wrote:
> Hi,
>
> I wonder if anyone has seen something like this.
>
> I have an FPGA design targeted at an Spartan xc3s1500 and using
> ISE8.2.
>
> We are using a spartan evaluation board with some 7 segment LED's.
>
> If I make minor changes to the pinout, sometimes the FPGA stops
> functioning completely.
-Just out of curiousity, why are you changing the pin outs??  For an
eval board, many pins are hard-wired to chips, LEDs, etc, and so the
pinouts must _not_ be changed!  You do have flexibility if FPGA pins
are connected to expansion connectors.

>What is interesting, is that the 7 segment LED's are not driven. The VHDL code for this is :
>
>   p_seven_seg : process(clk system_reset_n,)
>
>   begin
>     if(system_reset_n = '0')then
>       seven_seg_1 <= "1111111";
>     elsif(clk = '1'and clkt'event) then
>       case (conv_integer(p1)) is
>         when 0      =>
>           seven_seg_1 <= not("0111111");
>         when others =>
>           seven_seg_1 <= "1111111";
>       end case;
Bug 1 -  p_seven_seg : process(clk system_reset_n,)
  There should be a comma (,) between "clk" and "system_reset_n".
Remove the comma before ")".
Bug 2 - elsif(clk = '1' and clkt'event) then
  OK, is the clock named "clk" or "clkt" ??
  An alternate form is
        elsif rising_edge(clk) then

HTH
-Dave Pollum



Article: 123032
Subject: Re: Delaying a pulse train
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 14 Aug 2007 12:28:55 -0700
Links: << >>  << T >>  << A >>
"m" <martin.usenet@gmail.com> wrote in message 
news:1187117559.671533.286940@i38g2000prf.googlegroups.com...
>I have to delay a pulse train by a given number of clocks on the same
> domain as the pulse to be delayed.
>
> The best approach I can think of is to run a counter of sufficient
> width and log pulse transitions and states into a circular "pulse
> transition list" of sufficient depth.  After waiting for the desired
> number of clock transitions (the delay) an output counter of the same
> width as the input sample counter is allowed to start counting.  This
> counter is used to address the "pulse transition list" to generate a
> delayed output that matches the input.
>
> Using SelectRAM memory for delay is out of the question as too much
> memory would be required and it is needed elsewhere in the design.
>
>
> Can anyone suggest a better way to do this?  The incoming pulses are
> relatively regular and can be of any duration, from a few clocks to
> hundreds.
>
> Thanks,
>
> -Martin

The entire delay can be "a few" to "hundreds" of clocks and the overall 
delay can be 500us*150MHz=75000 periods.  How many pulses can be in transit 
at any one time?  hundreds?  Only one?  The transition list might be the 
lowest-resource approach, especially when using SRLs to maintain the list. 
I'm just not sure if 16 (or 32 or 64) elements are enough for your needs. 
You'll need a 17 bit counter to reach 500 us at 150 MHz.  It might be handy 
to guarantee clean operation by adding an 18th bit for pulse polarity.  The 
number of entries you'll need is twice the number of pulses you must 
accommodate. 



Article: 123033
Subject: Re: Xilinx Spartan FPGA : Strange Errors
From: moogyd@yahoo.co.uk
Date: Tue, 14 Aug 2007 12:53:21 -0700
Links: << >>  << T >>  << A >>
On 14 Aug, 21:16, Dave Pollum <vze24...@verizon.net> wrote:
> On Aug 14, 12:24 pm, moo...@yahoo.co.uk wrote:> Hi,
>
> > I wonder if anyone has seen something like this.
>
> > I have an FPGA design targeted at an Spartan xc3s1500 and using
> > ISE8.2.
>
> > We are using a spartan evaluation board with some 7 segment LED's.
>
> > If I make minor changes to the pinout, sometimes the FPGA stops
> > functioning completely.
>
> -Just out of curiousity, why are you changing the pin outs??  For an
> eval board, many pins are hard-wired to chips, LEDs, etc, and so the
> pinouts must _not_ be changed!  You do have flexibility if FPGA pins
> are connected to expansion connectors.
>
> >What is interesting, is that the 7 segment LED's are not driven. The VHDL code for this is :
>
> >   p_seven_seg : process(clk system_reset_n,)
>
> >   begin
> >     if(system_reset_n = '0')then
> >       seven_seg_1 <= "1111111";
> >     elsif(clk = '1'and clkt'event) then
> >       case (conv_integer(p1)) is
> >         when 0      =>
> >           seven_seg_1 <= not("0111111");
> >         when others =>
> >           seven_seg_1 <= "1111111";
> >       end case;
>
> Bug 1 -  p_seven_seg : process(clk system_reset_n,)
>   There should be a comma (,) between "clk" and "system_reset_n".
> Remove the comma before ")".
> Bug 2 - elsif(clk = '1' and clkt'event) then
>   OK, is the clock named "clk" or "clkt" ??
>   An alternate form is
>         elsif rising_edge(clk) then
>
> HTH
> -Dave Pollum

Hi,

Sorry for the confusion - the VHDL was cut and pasted (and
simplified). I wanted to simply show how "simple" the functionality
that is not working. It does compile (and the FPGA works 90% of the
time)

Anyway, to other points, the eval board has expansion connectors where
we can add eval boards and connect to test equipment. This is why I
change the pinout.

The design is timing clean (which of course depends on me constraining
it correctly). However, even with timing problems I would expect the
above logic to at least drive the O/P's.

I haven't locked all I/O's down - I will try this tomorrow.

One more note. I have an O/P bus called DVDD.  Is this likely to be an
issue for the Xilinx tool chain (it works most of the time).

Thanks,

Steven


Article: 123034
Subject: Re: Delaying a pulse train
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 14 Aug 2007 13:25:07 -0700
Links: << >>  << T >>  << A >>
Martin, to delay a 150 MHz bitstream by 500 us, you need to store
75000 bits.
If you cannot afford that on-chip, you must store it off-chip.
There is no other way, unless you are willing to think of data
compression (Huffman?)
Peter Alfke
============
On Aug 14, 12:10 pm, m <martin.use...@gmail.com> wrote:
> > Martin, have you thought of using the dual-ported BlockRAMs?
>
> It would consume too many BRAMs.  I need delays in the order of 500us
> at 150MHz.  That's about 5 BRAMs (Virtex2).  I need them for other
> portions of the design.
>
> It'd sure be easy though!
>
> -M



Article: 123035
Subject: Xilinx DDR2 SDRAM controller performance
From: bruce_hw_guy@hotmail.com
Date: Tue, 14 Aug 2007 13:53:53 -0700
Links: << >>  << T >>  << A >>
I am using the MIG generated DDR2 controller in a V5 device. The DDR2
runs at 266 MHz. I am meeting timing, but I am finding the performance
of the controller to be a little dissapointing. When I am reading and
writing 128 byte chunks of data to random locations (usually a new row
or bank), I am seeing about 28 % bus utilization, while my application
really requires closer to 60 % under these conditions.  I have two
questions:

1) Have others seen this type of performance with the MIG generated
DDR2 controller ?

2) Does anyone have experience with 3rd party IP that might come
closer to the 60 % utilization I require.  Thanks. -Bruce


Article: 123036
Subject: Re: Delaying a pulse train
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 14 Aug 2007 13:54:00 -0700
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1187123107.324950.325860@x35g2000prf.googlegroups.com...
> Martin, to delay a 150 MHz bitstream by 500 us, you need to store
> 75000 bits.
> If you cannot afford that on-chip, you must store it off-chip.
> There is no other way, unless you are willing to think of data
> compression (Huffman?)
> Peter Alfke

His original suggestion was to mark the edges on the input and replicate the 
edges to the output with a counter shifted by the needed delay, accumulating 
these transitions in a list.  As long as the number of transitions in the 
delay is small (compared to 75k, at least) his suggested approach is wholly 
adequate. 



Article: 123037
Subject: Re: Delaying a pulse train
From: m <martin.usenet@gmail.com>
Date: Tue, 14 Aug 2007 20:56:46 -0000
Links: << >>  << T >>  << A >>
> Martin, to delay a 150 MHz bitstream by 500 us, you need to store
> 75000 bits.
> If you cannot afford that on-chip, you must store it off-chip.
> There is no other way, unless you are willing to think of data
> compression (Huffman?)
> Peter Alfke

I have the module I described in the original post working just fine
right now.  So, for cases where the number of transitions during the
delay period isn't excessive, yes, there is another way.  I agree
though, that, if the intent was to store any random pulse train you'd
have no choice but to store and "replay" at a later time...requiring
BRAM.

-M



Article: 123038
Subject: Re: Delaying a pulse train
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 15 Aug 2007 09:15:21 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Martin, to delay a 150 MHz bitstream by 500 us, you need to store
> 75000 bits.
> If you cannot afford that on-chip, you must store it off-chip.
> There is no other way, unless you are willing to think of data
> compression (Huffman?)

  I think his edge-tag scheme is valid and is often used in
Logic Analysers, to get better apparent dynamic range.
  Of course it is more complex that a simple spinning delay buffer,
but it may be the Logic/BRAM trade off is worth it ?

-jg


Article: 123039
Subject: Re: Delaying a pulse train
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 15 Aug 2007 09:16:18 +1200
Links: << >>  << T >>  << A >>
m wrote:

>>Martin, have you thought of using the dual-ported BlockRAMs?
> 
> 
> It would consume too many BRAMs.  I need delays in the order of 500us
> at 150MHz.  That's about 5 BRAMs (Virtex2).  I need them for other
> portions of the design.
> 
> It'd sure be easy though!

What is your expected maximum edge count, in that 500us ?

=jg


Article: 123040
Subject: How to save simulation results in Xilinx ISE ?
From: Telenochek <elet.mirror@gmail.com>
Date: Tue, 14 Aug 2007 21:44:34 -0000
Links: << >>  << T >>  << A >>
Hi everyone,

I am using Xilinx ISE simulator for behavioral simulation of a large
circuit.
I would like to save simulated results, to avoid running the
simulation again, which takes quite some time.
However, when I use the "Save As" in Xilinx ISE, it DOES NOT save the
results.
I don't see any other options that would allow me to save data.

My ISE version is 8.2.03i

Any help would be greatly appreciated.
Thanks!
Tele


Article: 123041
Subject: Re: Delaying a pulse train
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 14 Aug 2007 15:42:42 -0700
Links: << >>  << T >>  << A >>
Huffman run-length encoding has been used successfully in early-
generation fax machines.
Whether that or any other compression (e.g. edge-detection) scheme is
good, depends on the characteristics of the bitstream in question.
Peter Alfke


Article: 123042
Subject: System ACE failure on ML405
From: Kunal <kunals.spam.account@gmail.com>
Date: Wed, 15 Aug 2007 00:38:18 -0000
Links: << >>  << T >>  << A >>
I keep running into a System ACE problem on the ML405 when trying to
get my own ACE file to load.

- I've properly formatted the CF card (as described in Answer Records
#14456), and I've verified this by copying the demo files over and
booting into them. The demos work fine, but when I select the custom
ACE file from the menu, it fails and the ERR led turns on.

- I've generated the files using the genace.tcl script provided with
the ml405 reference design (it contains the correct JTAG sequence for
that board). I've verified that the JTAG chain setup in genace is
correct (against what I read via iMPACT). I've tried using both
system.bit and the ELF-infused download.bit as the basis; both fail.

- I've replaced the old genace.tcl file in \EDK\data\xmd with the new
one that has the ml405's board information, and tried generating
through XPS, also to no avail

- Directly from iMPACT, I created an ACE file. I tried this on a clean
format of the CF, using one revision at 0, and I still got the same
result.

- I'm using EDK 8.2 SP3 on Windows 2000; using a 512 MB CF disk with a
95 MB FAT16 partition (the rest is the factory-shipped Linux
partition)

Is there anything specific in the actual bitstream that I may be
missing? e.g. does my bitstream need a System ACE controller?

Thanks,
Kunal


Article: 123043
Subject: Xilinx PACKER warning bout carry
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 14 Aug 2007 18:17:32 -0700
Links: << >>  << T >>  << A >>
What does this "PACKER" warning
mean?

Lut _ driving carry _ can not
be packed with the carry due
to conflict with the common
signal requirement between Lut
inputs and the Carry DI/MAND pins.
This would result in an extra Lut
for a feedthrough.

Here is the VHDL code:

 count_int_proc:process(clk)
 begin
 if(clk'event and clk='1')then
   if(reset='1')then
     count_int <= start_value;
   elsif( enable='1') then
     if(up='1' and count_int<max)then
       count_int<=count_int+1;
     elsif( down='1'and count_int>0) then
       count_int<=count_int-1;
     end if;
   end if;
 end if;
 end process;

Thanks,
Brad Smallridge
AI Vision






Article: 123044
Subject: Re: Delaying a pulse train
From: m <martin.usenet@gmail.com>
Date: Wed, 15 Aug 2007 01:17:39 -0000
Links: << >>  << T >>  << A >>
On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote:
> Huffman run-length encoding has been used successfully in early-
> generation fax machines.
> Whether that or any other compression (e.g. edge-detection) scheme is
> good, depends on the characteristics of the bitstream in question.
> Peter Alfke

I should have also mentioned that there's a need to delay more than
one such pulse streams (at least four).  That would require about
twenty 18K BRAMS...I use that many without going to a significantly
larger device.

-M



Article: 123045
Subject: Re: Delaying a pulse train
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 15 Aug 2007 14:13:28 +1200
Links: << >>  << T >>  << A >>
m wrote:
> On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote:
> 
>>Huffman run-length encoding has been used successfully in early-
>>generation fax machines.
>>Whether that or any other compression (e.g. edge-detection) scheme is
>>good, depends on the characteristics of the bitstream in question.
>>Peter Alfke
> 
> 
> I should have also mentioned that there's a need to delay more than
> one such pulse streams (at least four).  That would require about
> twenty 18K BRAMS...I use that many without going to a significantly
> larger device.

  If you have the time-headroom, you might be able to
compress what you have now, with a simple dictionary type lookup,
and a dT storage. One more level of lookup, but the average
storage/edge can drop.
How many bits do you store now, per edge ?

-jg


Article: 123046
Subject: Re: Delaying a pulse train
From: Peter Alfke <alfke@sbcglobal.net>
Date: Tue, 14 Aug 2007 21:27:11 -0700
Links: << >>  << T >>  << A >>
If run-length (Huffman) encoding is not your favorite, you might think
about one external SRAM for all four bitstreams. You could go byte-
wide which reduces the frequency, then time-multiplex the two ports,
so that you only need a 6-ns cycle-time relatively small external
SRAM. This assumes that you four bitstreams use a common clock. The
possibilities are endless...
Peter Alfke

On Aug 14, 6:17 pm, m <martin.use...@gmail.com> wrote:
> I should have also mentioned that there's a need to delay more than
> one such pulse streams (at least four).  That would require about
> twenty 18K BRAMS...I use that many without going to a significantly
> larger device.
>
> -M



Article: 123047
Subject: Re: xst fails...
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Wed, 15 Aug 2007 08:47:41 +0200
Links: << >>  << T >>  << A >>
I tried this, however this still doesn't work.
I started xst now from the console and now I see that I get a memory
violation at that certain point.

I will use Precision from Mentor Graphics from now on for the synthesis.

Matthias


Brian Drummond schrieb:
> On Tue, 14 Aug 2007 12:32:30 +0200, Matthias Alles
> <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de> wrote:
> 
>> There is nothing of interest in the output:
>>
>> INFO:Xst:2261 - The FF/Latch <configure.parallelism_2> in Unit <hws> is
>> equivalent to the following 155 FFs/Latches, which will be removed :
> 
> 
> Anything in the synthesis report file (.syr)?
> 
> Since the error appears to be near register removal, it  may be worth
> turning OFF "equivalent register removal" and seeing if the error
> remains.
> 
> - Brian

Article: 123048
Subject: Re: System ACE failure on ML405
From: Torsten Landschoff <t.landschoff@gmx.de>
Date: Wed, 15 Aug 2007 01:17:02 -0700
Links: << >>  << T >>  << A >>
Hi Kunal,

On 15 Aug., 02:38, Kunal <kunals.spam.acco...@gmail.com> wrote:
> I keep running into a System ACE problem on the ML405 when trying to
> get my own ACE file to load.
>
> - I've properly formatted the CF card (as described in Answer Records
> #14456), and I've verified this by copying the demo files over and
> booting into them. The demos work fine, but when I select the custom
> ACE file from the menu, it fails and the ERR led turns on.

I gather from this that your board actually has a System ACE
controller which is able to configure your FPGA using the Compact
Flash card as input.

> - I've generated the files using the genace.tcl script provided with
> the ml405 reference design (it contains the correct JTAG sequence for
> that board). I've verified that the JTAG chain setup in genace is
> correct (against what I read via iMPACT). I've tried using both
> system.bit and the ELF-infused download.bit as the basis; both fail.

What application (ELF file) are you using for download.bit? You should
use download.bit and it should contain the bootloop.

> - I've replaced the old genace.tcl file in \EDK\data\xmd with the new
> one that has the ml405's board information, and tried generating
> through XPS, also to no avail

No idea what the difference is between those files. What is your
memory setup? Do you by chance use any instruction memory?
(isocm_cntrl or something like that)

> - Directly from iMPACT, I created an ACE file. I tried this on a clean
> format of the CF, using one revision at 0, and I still got the same
> result.

iMPACT failed on me as well so that's nothing special ;-)

> Is there anything specific in the actual bitstream that I may be
> missing? e.g. does my bitstream need a System ACE controller?

I think the board has System ACE? How else do you load the ACE files?

Greetings, Torsten


Article: 123049
Subject: Re: System ACE failure on ML405
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Wed, 15 Aug 2007 09:29:15 -0000
Links: << >>  << T >>  << A >>
On 15 Aug., 02:38, Kunal <kunals.spam.acco...@gmail.com> wrote:
> I keep running into a System ACE problem on the ML405 when trying to
> get my own ACE file to load.
>
> - I've properly formatted the CF card (as described in Answer Records
> #14456), and I've verified this by copying the demo files over and
> booting into them. The demos work fine, but when I select the custom
> ACE file from the menu, it fails and the ERR led turns on.

Try the well hidden AR 25046
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=25046

Kolja Sulimma




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