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 105600

Article: 105600
Subject: Re: Which PCI core for Cyclone II board?
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 27 Jul 2006 10:55:19 +1000
Links: << >>  << T >>  << A >>
Brian McFarland wrote:

> Well I gave up on trying to find free ( and legal :-/ ) info about PCI
> online and ordered the mindshare PCI book.  It hasn't arrived yet, but
> I began just writing my own PCI module.  I was kinda hoping to be able
> to do this project w/o getting too deep into the specs of PCI, but I
> don't think that's going to happen.

I'd suggest hooking up the opencores PCI core if you have available
hardware just to get a feel for what's involved. Once you get the gist
of how it hangs together it's really quite simple to hook up something
to the back end. The DMA controller shouldn't be that difficult either
(although I realise I'm speaking with the benefit of hindsight).

BTW I'd suggest you look into CDBG from probo.com when bringing up a PCI
core.

From there, you could invest a little time in benchmarking your
application. Even if you end up deciding that the opencores PCI core is
not the way to go, you've no doubt (a) learned something about PCI and
(b) established a peformance testbench for your final solution.

BTW the Mindshare book is certainly going to be a big help in ramping up
on PCI.

IMHO, you're going to need bus-mastering DMA to get 54MB/s out of PCI,
and that's a *lot* of effort to do from scratch! Just verifying the
design is going to be a mammoth effort - take a look at the size of the
testbench module in the opencores PCI design to get an idea!!!

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: 105601
Subject: Hold violation in Virtex 4
From: "TT" <tramie_tran@yahoo.com>
Date: 26 Jul 2006 17:55:34 -0700
Links: << >>  << T >>  << A >>
Hi everyone:

I'm new to FPGA design (have always worked with ASIC before.) I'm
working with Virtex 4, and from time to time, I'd get hold violations
on one of my clocks, which XST cannot fix. This clock is driven with an
IBUFG. I don't know how to work around this problem other than
inserting delays with gates myself. I'd appreciate any feedback/idea on
this problem.

Thank you,
-TT


Article: 105602
Subject: Re: Which PCI core for Cyclone II board?
From: "johnp" <johnp3+nospam@probo.com>
Date: 26 Jul 2006 18:20:53 -0700
Links: << >>  << T >>  << A >>
If you decide to use CDBG from probo.com to play
with your PCI design, you should note that the version
on the web only works with Win98 and earlier.

I haven't released a Win2K++ version for free usage yet,
but we do have one (and a Linux version as well) that are used
internally.

CDBG has two modes of operation:
  - one mode has the tradition peek/poke commands
  - one mode is a C interpreter that lets you write C code
    without screwing around with DPMI, etc.

ALSO - I suspect it will be next to impossible to get 54MB/sec
transfer rates without bus mastering.

John Providenza

Mark McDougall wrote:
> Brian McFarland wrote:
>
> > Well I gave up on trying to find free ( and legal :-/ ) info about PCI
> > online and ordered the mindshare PCI book.  It hasn't arrived yet, but
> > I began just writing my own PCI module.  I was kinda hoping to be able
> > to do this project w/o getting too deep into the specs of PCI, but I
> > don't think that's going to happen.
>
> I'd suggest hooking up the opencores PCI core if you have available
> hardware just to get a feel for what's involved. Once you get the gist
> of how it hangs together it's really quite simple to hook up something
> to the back end. The DMA controller shouldn't be that difficult either
> (although I realise I'm speaking with the benefit of hindsight).
>
> BTW I'd suggest you look into CDBG from probo.com when bringing up a PCI
> core.
>
> From there, you could invest a little time in benchmarking your
> application. Even if you end up deciding that the opencores PCI core is
> not the way to go, you've no doubt (a) learned something about PCI and
> (b) established a peformance testbench for your final solution.
>
> BTW the Mindshare book is certainly going to be a big help in ramping up
> on PCI.
>
> IMHO, you're going to need bus-mastering DMA to get 54MB/s out of PCI,
> and that's a *lot* of effort to do from scratch! Just verifying the
> design is going to be a mammoth effort - take a look at the size of the
> testbench module in the opencores PCI design to get an idea!!!
>
> 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: 105603
Subject: Re: Hold violation in Virtex 4
From: "Bob" <nimby1_NEEDSPAM@earthlink.net>
Date: Thu, 27 Jul 2006 02:00:06 GMT
Links: << >>  << T >>  << A >>

"TT" <tramie_tran@yahoo.com> wrote in message 
news:1153961734.840434.288510@m79g2000cwm.googlegroups.com...
> Hi everyone:
>
> I'm new to FPGA design (have always worked with ASIC before.) I'm
> working with Virtex 4, and from time to time, I'd get hold violations
> on one of my clocks, which XST cannot fix. This clock is driven with an
> IBUFG. I don't know how to work around this problem other than
> inserting delays with gates myself. I'd appreciate any feedback/idea on
> this problem.
>
> Thank you,
> -TT
>

The IBUFG is essentially the clock input pin buffer. The IBUFG is not 
intended to drive the fabric. The low-skew global clock net are driven by 
BUFGs (aka,BUFGMUX). So, typically you connect the IBUFG output to the BUFG 
input. I don't think you can get hold violations if the fabric is clocked by 
a BUFG.

Another typical connection is if you use a DCM (for phase deskew, phase 
shifting, clock multiplication/division, etc...). Then, the IBUFG drives a 
DCM input, a DCM output will then drive a BUFG input, and the BUFG output 
will also be routed back to the DCM feedback input (and, of course drive the 
fabric clock inputs).

Bob



Article: 105604
Subject: Re: Hold violation in Virtex 4
From: "Bob" <nimby1_NEEDSPAM@earthlink.net>
Date: Thu, 27 Jul 2006 02:19:10 GMT
Links: << >>  << T >>  << A >>

"Bob" <nimby1_NEEDSPAM@earthlink.net> wrote in message 
news:G6Vxg.5844$157.5522@newsread3.news.pas.earthlink.net...
>
> "TT" <tramie_tran@yahoo.com> wrote in message 
> news:1153961734.840434.288510@m79g2000cwm.googlegroups.com...
>> Hi everyone:
>>
>> I'm new to FPGA design (have always worked with ASIC before.) I'm
>> working with Virtex 4, and from time to time, I'd get hold violations
>> on one of my clocks, which XST cannot fix. This clock is driven with an
>> IBUFG. I don't know how to work around this problem other than
>> inserting delays with gates myself. I'd appreciate any feedback/idea on
>> this problem.
>>
>> Thank you,
>> -TT
>>
>
> The IBUFG is essentially the clock input pin buffer. The IBUFG is not 
> intended to drive the fabric. The low-skew global clock net are driven by 
> BUFGs (aka,BUFGMUX). So, typically you connect the IBUFG output to the 
> BUFG input. I don't think you can get hold violations if the fabric is 
> clocked by a BUFG.
>
> Another typical connection is if you use a DCM (for phase deskew, phase 
> shifting, clock multiplication/division, etc...). Then, the IBUFG drives a 
> DCM input, a DCM output will then drive a BUFG input, and the BUFG output 
> will also be routed back to the DCM feedback input (and, of course drive 
> the fabric clock inputs).
>
> Bob
>
>

Also, in V4 there are "local" clocking options. The pins labeled "CC" also 
have this thng called a BUFIO (local clock buffer). BUFIOs can drive IOB 
clock resources. BUFIOs can also drive BUFRs. BUFRs can drive (some of) the 
fabric (as do BUFGs).

It helps to have your own local dedicated FAE. Otherwise, you need to RTFM. 
I hate reading the f'ing manuals, so I have our FAE's phone number 
memorized. He has to answer our questions or we'll think bad thoughts about 
him, and if you're a Twilight Zone fan then you'll understand the 
ramifications of this.

Bob



Article: 105605
Subject: Re: Which PCI core for Cyclone II board?
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 27 Jul 2006 12:40:50 +1000
Links: << >>  << T >>  << A >>
johnp wrote:

> If you decide to use CDBG from probo.com to play
> with your PCI design, you should note that the version
> on the web only works with Win98 and earlier.

Yes, but if you're constantly re-configuring your FPGA w/PCI core, then
you'll be re-booting constantly as well. The most time-efficient way
I've found to do bring-up of a PCI core, or even back-end peripherals,
is to have *DOS* booting off your HDD and run CDBG from there.

> CDBG has two modes of operation:
>   - one mode has the tradition peek/poke commands
>   - one mode is a C interpreter that lets you write C code
>     without screwing around with DPMI, etc.

Yes, the C interpreter is quite nice for 'scripting' tests. I brought up
the opencores IDE controller with opencores DMA and opencores PCI using
C code to do both PIO and DMA IDE accesses.

The nice part was the fact that I could transcribe the C code almost
line-for-line into Verilog for the equivalent HDL testbench routines.

And for further re-usability, I ended up using the OCIDE core in a
NIOS-based design (no PCI), which allowed me then to use the original
CDBG C code almost unchanged as test routines for that project too!

So thanks John, you've saved a lot of time for me at least!

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: 105606
Subject: Re: Spartan 3 clock to output tristate timing
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 26 Jul 2006 19:53:39 -0700
Links: << >>  << T >>  << A >>
Thanks to all who posted.  I decided to chill out and just go passive
on this.  I have been butting heads a lot and have won every fight on
the facts.  But I am just too sick of this.  So I am doing a timing
analysis which will either end up specifying what the FPGA needs to
meet (I will have to dig into the VHDL to understand the design) or I
will just leave the relevant holes and explain to the superiors that
this is the info I am not getting.  I will need to dig into the design
either way to make sure I understand which timing parameters really are
an issue and which are not.  Some of the input setup times *could* be
an issue depending on whether they are latching them or not.

For now I have analyzed the timing to the memory chip and believe it or
not, there is a small bug!  The timing spec on the DSP is not really
written correctly for an async interface.  All the timing is relative
to the internal clock, so you have to add a couple of parameters to get
the timing between the strobe and the setup/hold times on the data.
Turns out the strobe can go away 2 ns before the clock edge that
latches the read data. So the memory chip has to have a 2 ns hold time
which it doesn't have.  I don't think this will be a problem, but it
does not meet formal timing analysis.


Nico Coesel wrote:
> Can't you shove the whole problem upwards? And see what is falling
> down again? It seems to me you'll need to know how the FPGA's IOBs are
> used in order to know what timing to expect.

I originally tried this, but management is very weak.  I went around
for two weeks on an issue of a capacitor with the software guy.  The
project manager kept taking his side even after I proved him wrong.
The software guy came back with bogus test data and it was only after I
showed the manager that the data was not just two different value caps,
but two different boards!  So management is not just weak, but also
poorly informed (read that as too stupid to know when they are being
mislead).

We have some good engineers and we have some "political" engineers who
think they need to spend their time making themselves "look" good
rather than "doing" good.  I can't seem to figure out how to do my job
correctly without having problems from some of these types.


> However, based on your statement that the clock period is approx 10ns,
> they must have used the flipflops inside the IOB. Each IOB has 6
> flipflops. 2 to control the output enable, 2 to control the output and
> 2 to capture the input. The reason why there are 2 flipflops for each
> function is to be able to use the IOB at double datarate (DDR). The
> flipflops can be programmed so that one will act on the rising edges
> and the other one will act on the falling edges.

I can't say exactly what they did.  The interface is not synchronous.
The DSP specs the timing on the interface relative to the CLKOUT which
is a low voltage clock at the CPU speed.  The clock they are using is
CLKMEM which is not used in the spec for the async memory interface.
It is not the same speed or the same delay.  So the control signals are
in reality asynch to the clock.  The FPGA treats them as asynch and
goes through two registers for metastability reduction... at least that
is what I am told.

> The timing path from these flipflops to the actual pin is well
> documented. However, you'll still need to know whether they switched
> IOB_DELAY on or off for the input path.

I could not find this documentation for the tristate path.  The data
sheet gives specs on timing for the path from the clock input pin to
the output pin using the IOB FF that clocks the data, but no such
similar spec exists from the clock input pin to the output pin going
tristate when using the IOB tristate FF.  I will check the design
tomorrow and see if that is what the design uses.  Even so, I will have
to get the delay from the tools since it is not in the data sheet.


Article: 105607
Subject: Re: Spartan 3 clock to output tristate timing
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 27 Jul 2006 03:39:26 GMT
Links: << >>  << T >>  << A >>
A possibly simple test might be to write a simple testbench model to model 
the DSP to write and read back some registers.  During a write cycle keep 
the data bus unknown until the latest possible time that the spec says 
before the data will be valid and then also make it unknown at precisely the 
earliest time that the spec for the part says that the bus starts going 
tri-state or otherwise unknown.  Do the same for the address bus relative to 
the read/write controls.

Since the spec doesn't reference timing relative to the clock that the FPGA 
is using than have the model start and end cycles at various points relative 
to the clock cycle (say check every 1 or 2 ns throughout the entire 10 ns 
clock period).

If all the registers read back correctly it doesn't say that all the timing 
works out but at least it's not totally out to lunch ('someone' would still 
need to do the timing analysis).  But if anything does read back with 
unknowns than it says that there definitely is a problem and you should be 
able to punt it back to the FPGA guys and say "Here is a model of the bus 
that meets the spec but when connected to your design it fails".

This all assumes that the bus model is a relatively simple one (since I'm 
not actually familiar with the TMS320VC5510 itself).

KJ 



Article: 105608
Subject: EDK : *.bit and *.elf Files
From: Olli <Emperor_@gmx.de>
Date: Thu, 27 Jul 2006 00:49:49 -0700
Links: << >>  << T >>  << A >>
Hello Iím working with the EDK and now I have got a question. At the moment I download the Hardware with the EDK and then I download and start the Software with the debuger. How can I load the Software and Hardware into the Flash, so that I can start run the system without the JTAG chain? With Impact I can only load the Hardware into the Flash and it works. There is an option in the EDK to load the software into the Flash but that doesnít works fine and I still have to use XMD. I there a possibility to put the *.elf and *.bit file together?

Now my second question: I build a sytem which uses uc/OS II and the Micrium TCP/IP stack and I have got a timing problem. I created an ISR for a module with a little arithmetic operation to measure the time it will take to solve it. It takes around 2us for 5 assembler instructions. Furthermore it takes around 20us to enter the interruptconrollerhandler after the hardware generated the interrupt. Could it be that this problem exits because I use the debugger to run the Software?

Iím using the ML403 evalboard and the Microblaze(100MHz).

I hope somebody can help me.

Cu Olli

Article: 105609
Subject: Re: EDK : *.bit and *.elf Files
From: Ron <News5@spamex.com>
Date: Thu, 27 Jul 2006 01:39:03 -0700
Links: << >>  << T >>  << A >>
Olli wrote:
> How can I load the Software and Hardware into the Flash, 
> so that I can start run the system without the JTAG chain?

Usually there is an option to create a PROM file instead of a bitstream 
file. In Xilinx Project Navigator's "Process View", underneath the 
"Generate Programming File" process is the selection "Generate PROM, 
ACE, or JTAG File," which I assume is for creating a file to load the 
serial PROM that contains the design that runs at power on.

You may need to change some jumpers in order to program the serial PROM 
also.

Ron

Article: 105610
Subject: Re: EDK : *.bit and *.elf Files
From: Olli <Emperor_@gmx.de>
Date: Thu, 27 Jul 2006 02:03:24 -0700
Links: << >>  << T >>  << A >>
Hi Where do I find the Project Navigator? I'm only working with the EDK and I use Impact to generate an *.EXO file from the EDK *.bit file and I can load my hardware from the flash. My problem is ,that the *.bit file from the EDK only comprised the hardware and not the software. I donít now how I can create a file which contains the hardware and the software ( my program and a bootloader, which runs my software in the ddr-ram).

Olli

Article: 105611
Subject: IOBDELAY and DCM
From: "RobertP." <r_p_u_d_l_i_k@poczta.onet.pl>
Date: Thu, 27 Jul 2006 12:05:26 +0200
Links: << >>  << T >>  << A >>
Hello,
I have a design with two FPGAs (Xilinx Spartan3). Both use common clock, 
and both can send data to the other one in a synchronous manner. Because 
of possible clock skew, the critical seems to be meeting input hold time 
requirements (setup is not a problem). This can be solved by adding 
additional delay on the data path, and I wanted to use IOBDELAY element 
for this purpose.
But I'm not sure how to calculate the hold time of the input flip-flop 
when the IOBDELAY is added and a DCM is used. The datasheet specifies 
only TPHDCM (IOBDELAY=NONE, DCM used) or TPHFD (IOBDELAY=IFD, DCM not used).
There is also TIOICKPD parameter (hold time at the IFF in respect to 
clock on this flip-flop, and not on the global clock pin), but then I'm 
not sure how to calculate the skew between IFF clock and clock on the 
input pin (the DCM is used).
Any ideas how to approach this problem?

-- 
Regards
RobertP.

Article: 105612
Subject: Re: IOBDELAY and DCM
From: "Gabor" <gabor@alacron.com>
Date: 27 Jul 2006 05:46:37 -0700
Links: << >>  << T >>  << A >>
Once your design is placed & routed, you can get a timing report
that gives you the setup and hold requirements of each input
to the clock pin(s).  You can then adjust the clock timing if necessary
using the fixed or variable delay of the DCM (Fixed is easier if you
can find a value that works).  By the way, if you make the timing
adjustment with the DCM, you may find it easier to remove the
IOBDELAY as it will give you a larger setup / hold window to center
the clock in.  Also note that the clock to output timing when measured
from the clock input pin and not the internal global net can be quite
long, so meeting hold time may not be as much problem as you
might think from reading the IOB timing numbers in the data sheet.

HTH,
Gabor

RobertP. wrote:
> Hello,
> I have a design with two FPGAs (Xilinx Spartan3). Both use common clock,
> and both can send data to the other one in a synchronous manner. Because
> of possible clock skew, the critical seems to be meeting input hold time
> requirements (setup is not a problem). This can be solved by adding
> additional delay on the data path, and I wanted to use IOBDELAY element
> for this purpose.
> But I'm not sure how to calculate the hold time of the input flip-flop
> when the IOBDELAY is added and a DCM is used. The datasheet specifies
> only TPHDCM (IOBDELAY=NONE, DCM used) or TPHFD (IOBDELAY=IFD, DCM not used).
> There is also TIOICKPD parameter (hold time at the IFF in respect to
> clock on this flip-flop, and not on the global clock pin), but then I'm
> not sure how to calculate the skew between IFF clock and clock on the
> input pin (the DCM is used).
> Any ideas how to approach this problem?
> 
> -- 
> Regards
> RobertP.


Article: 105613
Subject: Re: IOBDELAY and DCM
From: "RobertP." <r_p_u_d_l_i_k@poczta.onet.pl>
Date: Thu, 27 Jul 2006 15:23:08 +0200
Links: << >>  << T >>  << A >>
Gabor wrote:
> Also note that the clock to output timing when measured
> from the clock input pin and not the internal global net can be quite
> long, so meeting hold time may not be as much problem as you
> might think from reading the IOB timing numbers in the data sheet.
>

Why clock to output would be longer than specified in the datasheet 
(TICKOFDCM - pin-to-pin clock to output)?
Also there is no Min TICKOFDCM specified - I found some info about how 
to estimate it (25% of worst case, but some people think it is not 
conservative enough).

-- 
Regards
RobertP.


Article: 105614
Subject: Re: Spartan 3 clock to output tristate timing
From: John_H <johnhandwork@mail.com>
Date: Thu, 27 Jul 2006 13:42:08 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
<snip>

>> The timing path from these flipflops to the actual pin is well
>> documented. However, you'll still need to know whether they switched
>> IOB_DELAY on or off for the input path.
> 
> I could not find this documentation for the tristate path.  The data
> sheet gives specs on timing for the path from the clock input pin to
> the output pin using the IOB FF that clocks the data, but no such
> similar spec exists from the clock input pin to the output pin going
> tristate when using the IOB tristate FF.  I will check the design
> tomorrow and see if that is what the design uses.  Even so, I will have
> to get the delay from the tools since it is not in the data sheet.

Rather than delving deep into the design, perhaps Timing Analyzer can 
supply a lot of information.  If the I/O are unconstrained, the 
Analyze/Against Auto Generated Design Constraints will give you the 
input and output timing.  These can show the full combinatorial paths 
(or lack thereof) between the pads and registers.  The Data Sheet 
section of the report will also give you Tcko, Tsu, and Th for the 
design.  You may even find the IOBDELAY values here rather than having 
to go to the pad report.

Article: 105615
Subject: Re: ISE 8.2i and EDK8.1i
From: Joseph Samson <user@example.net>
Date: Thu, 27 Jul 2006 14:06:35 GMT
Links: << >>  << T >>  << A >>
GaLaKtIkUsô wrote:
> Hi all,
> I would like to know before upgrade if EDK8.1i is compatible with
> ISE8.2i.
> 
> Thanks in advance
> 
Just found this out yesterday: EDK8.1i won't even run if ISE8.1 isn't 
installed. A co-worker with little free disk space uninstalled his 
ISE8.1i and installed ISE8.2i. Yesterday, he wanted to run XMD and found 
that EDK8.1i won't start up because it can't find ISE8.1i. It's possible 
to have several versions of EDK and ISE installed (if you have the room).


---
Joe Samson
Pixel Velocity

Article: 105616
Subject: Re: *.bit and *.elf Files
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 27 Jul 2006 10:25:10 -0400
Links: << >>  << T >>  << A >>
"Olli" <Emperor_@gmx.de> wrote in message news:ee9d396.-1@webx.sUN8CHnE...
> Hello I'm working with the EDK and now I have got a question. At the
moment I download the Hardware
> with the EDK and then I download and start the Software with the debuger.
How can I load the Software
> and Hardware into the Flash, so that I can start run the system without
the JTAG chain? With Impact I can
> only load the Hardware into the Flash and it works. There is an option in
the EDK to load the software into
> the Flash but that doesn't works fine and I still have to use XMD. I there
a possibility to put the *.elf and *.bit
> file together?

There is more than one FLASH memory on ML403. Read some documentation.
Basically, you need to create a bootloader application, which can be done
with the FLASH programming tool in EDK while writing your main *.elf file
into the Linear FLASH. Then you need to update your bitstream with the
bootloader elf (this by default will create download.bit file) and then
program the Platform FLASH using Impact.

/Mikhail






Article: 105617
Subject: Guided MAP/PAR in ISE
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 27 Jul 2006 10:44:10 -0400
Links: << >>  << T >>  << A >>
Hi all,

I was wondering if anyone had succeded in saving time by using guided
MAP/PAR. I personally find that every time I want to use it, even in the
most obvious cases when 99.9% of design hasn't changed,  I then have to
re-run everything from scratch anyway...


Thanks,
/Mikhail



Article: 105618
Subject: Re: 2Khz clock signal from 50Hz main frequency with ADPLL
From: "raso" <rasit.sahin@yahoo.co.uk>
Date: 27 Jul 2006 08:20:27 -0700
Links: << >>  << T >>  << A >>
>>More or less. Wait a tick. Look at the data sheet of the 74xx297, it
>>says the lock range (pull range) of the PLL is
>>delta_f_max = fc * M / (2*K*N )
>>using your values
>>delta_f_max = 50 Hz * 600000 / (2* 300000 * 40) = 1.25 Hz
>>Hmm, this should be enought.

I/D counter is a 2 divider.  In locked condition, its output is 30MHz/2
= 15MHz.
Therefore, in addition to N=40 divider, I have to use an f_out
prescalar (=7500). In
this case :

delta_f_max = fc * M / (2*K*N*f_out_prescalar )
delta_f_max = 50 Hz * 600000 / (2* 300000 * 40 * 7500) = 1.25/7500 Hz

Is this correct?

Isa


Falk Brunner wrote:
> raso schrieb:
> > Hi Jon,
> >
> > Falk Brunner sent me his VHDL implementation of 74LS297. I modified it
> > so that K-counter and I/D counter (DCO) run at system clock which is
> > 30MHz.
>
> Wasn't it already this way?
>
> > The system has following blocks;
> >
> > - The first component is an JKFF based phase detector.
> > - Then, there is a K-counter operating at 30MHz. With 30MHz clock, a
> > full 50Hz
> > period means M=30e6/50=600000 ticks. For minimum jitter, modulus of K
> > counter is set M/2 which is 300000. The borrow pulse decreases the
> > modulus of I/D counter (2KHz DCO) while carry pulse increases it by 1.
> > So in locked condition, it generates 1 carry and 1 borrow pulse within
> > one 50Hz period and they cancel each other.
> > - I/D counter is a DCO (modulus counter). It operates  at 30MHz. When
> > it is locked to 50Hz it has modulus of 15000. When 50Hz changes, the
> > borrow and carry pulses should adjust the modulus of I/D counter (carry
> > pulse increases the modulus by 1, and borrow decreases it by 1). By
> > this way, period of 2kHz pulses is adjusted according to 50Hz input.
> > - N-Counter which devides 2Khz clock by 40.
> >
> > The only parameter that I can play with is the modulus of K counter.
>
> More or less. Wait a tick. Look at the data sheet of the 74xx297, it
> says the lock range (pull range) of the PLL is
>
> delta_f_max = fc * M / (2*K*N )
>
> using your values
>
> delta_f_max = 50 Hz * 600000 / (2* 300000 * 40) = 1.25 Hz
>
> Hmm, this should be enought.
>
> > I can't use direct implementation of 74LS297. Because, it syncronises
> > f_in and f_out by inserting or deleting 2KHz pulses (I/D pulses). I
>
> This is not true. It inserts master clock cycles, in your case, 30 MHz
> clocks. Which are 1/3000 of a 2 kHz period.
>
> > can't tolerate inserting or deleting 2KHz pulses. It has to keep the
> > number of 2kHz pulses as 40 in each 50Hz period.
> 
> Sure, otherwise you couldnt call it PLL ;-)
> 
> Regards
> Falk


Article: 105619
Subject: Re: An idea for a product (FPGA/ASIC based)
From: "Brannon" <brannonking@yahoo.com>
Date: 27 Jul 2006 08:21:48 -0700
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:
> Hi Brannon,
> Can you explain further about a full huffman analysis for JPEG?
>
> I have no any knowledge about JPEG and what books you recommend about
> the topics?

Google this: "MIL-STD-188-198A"

and Google this: "itu-t81.pdf"

Those are two fundamental JPEG documents. There is one nice book on the
topic I've seen, but I don't have a copy handy. If you can understand
the above two documents, you won't need it. It has a pink cover. And if
you don't know what Huffman encoding is, you had better Google that one
as well.


Article: 105620
Subject: Re: Guided MAP/PAR in ISE
From: "Brannon" <brannonking@yahoo.com>
Date: 27 Jul 2006 08:35:45 -0700
Links: << >>  << T >>  << A >>
> I was wondering if anyone had succeded in saving time by using guided
> MAP/PAR. I personally find that every time I want to use it, even in the
> most obvious cases when 99.9% of design hasn't changed,  I then have to
> re-run everything from scratch anyway...

80% of the times I ran it, it crashed. The other 20% of the time it
took longer than running without it. That includes all versions from
6.1.1-8.1.1 with a range of test cases. I personally think the thing is
a joke. It's a great idea, nice sales pitch, and terrible
implementation. I submitted some bugs that were supposedly to be fixed
in 8.2, but I haven't tried it yet. Apparently it doesn't play nice
with overly tight constraints or duplicated registers.

Here's a few thoughts on what I would have expected with "exact" mode
and never saw:

If the incoming code
1. has less (or equal) logic than that of the previous run
2. and the logic it has matches that of the previous run
3. and the previous run passed timespecs
then that compile should take no time at all.

If the incoming code
1. has all the same logic as the previous run
2. in addition to some more logic
then the compile time should take the same amount of time as the
difference of the logic on a smaller chip representing the amount of
available logic.

If the net names don't match exactly but the logic names do, well good
freak, make some assumptions about the net names. That issue turns the
whole thing into a major headache.


Article: 105621
Subject: Rocket IO as a high speed sampler
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Thu, 27 Jul 2006 17:40:45 +0200
Links: << >>  << T >>  << A >>
Hi everyone, (especially those Xilinx chaps) :-)

I've been having an interesting debate with a colleague here, regarding 
Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to 
make a really high speed signal sampler in the fabric of one of these FPGAs 
by using the Rocket IO in a custom manner. I'm talking some GS/s

We figure using a local clock of 100M, should be mutiplied by 20 inside the 
rocket IO, giving 20 bits per 100M period that can be shuffled to get some 
indication of the input waveform. i.e. a 2G sampler.

Ok, ignoring the hugely important fact that FPGA has to be able to process 
this, and that the PCB has to be well designed, and that the input signal 
might have some new frequency and electrical constraints, are there any 
pitfalls we've missed?  btw: the idea comes from an expansion Figure-7 of:
http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF

Are there any potential flaws in these ideas anyone can see?

Thanks in advance,
Ben 



Article: 105622
Subject: Re: EDK Using External Ports to toggle FPGA pins
From: "Kyle H." <kyle.hable@gmail.com>
Date: 27 Jul 2006 08:42:39 -0700
Links: << >>  << T >>  << A >>
Ok, So I think I can get past that part for now.

Now, I'm trying to recreate the tutorial.  I notice is Base System
Builder it doesnt list the LCD screen as a periphial.  So I am trying
to add it manually.  I have the pcore and the drivers, I can add it as
a periphial and set it up on the bus sucessfully, but I am having
issues with the drivers.  I copied them to the include folder and the
folder that my test code is in, and I cannot get it to comiple
correctly.  This is possibly my lack of knowledge in the C language?

I'm starting to get the hang of all this.  I'm fairly fresh outta
school (getting a little ripe) but I don't work with anyone that's had
more experience than me in this, so I'm finding this a bit
frustraiting, expecially when I have a project I am to be working on!

I'm also messing around with a bootloaded design, and downloading to
the flash and external ram.  From reading over the tutorial it looks
like XPS/EDK builds a bootloader for you...I suppose a basic
bootloader.  Well I'll see what I can come up with.

Thanks for your support!


Article: 105623
Subject: Re: Hold violation in Virtex 4
From: "TT" <tramie_tran@yahoo.com>
Date: 27 Jul 2006 08:59:38 -0700
Links: << >>  << T >>  << A >>
Thanks Bob for the info.

Bob wrote:
> "Bob" <nimby1_NEEDSPAM@earthlink.net> wrote in message
> news:G6Vxg.5844$157.5522@newsread3.news.pas.earthlink.net...
> >
> > "TT" <tramie_tran@yahoo.com> wrote in message
> > news:1153961734.840434.288510@m79g2000cwm.googlegroups.com...
> >> Hi everyone:
> >>
> >> I'm new to FPGA design (have always worked with ASIC before.) I'm
> >> working with Virtex 4, and from time to time, I'd get hold violations
> >> on one of my clocks, which XST cannot fix. This clock is driven with an
> >> IBUFG. I don't know how to work around this problem other than
> >> inserting delays with gates myself. I'd appreciate any feedback/idea on
> >> this problem.
> >>
> >> Thank you,
> >> -TT
> >>
> >
> > The IBUFG is essentially the clock input pin buffer. The IBUFG is not
> > intended to drive the fabric. The low-skew global clock net are driven by
> > BUFGs (aka,BUFGMUX). So, typically you connect the IBUFG output to the
> > BUFG input. I don't think you can get hold violations if the fabric is
> > clocked by a BUFG.
> >
> > Another typical connection is if you use a DCM (for phase deskew, phase
> > shifting, clock multiplication/division, etc...). Then, the IBUFG drives a
> > DCM input, a DCM output will then drive a BUFG input, and the BUFG output
> > will also be routed back to the DCM feedback input (and, of course drive
> > the fabric clock inputs).
> >
> > Bob
> >
> >
>
> Also, in V4 there are "local" clocking options. The pins labeled "CC" also
> have this thng called a BUFIO (local clock buffer). BUFIOs can drive IOB
> clock resources. BUFIOs can also drive BUFRs. BUFRs can drive (some of) the
> fabric (as do BUFGs).
>
> It helps to have your own local dedicated FAE. Otherwise, you need to RTFM.
> I hate reading the f'ing manuals, so I have our FAE's phone number
> memorized. He has to answer our questions or we'll think bad thoughts about
> him, and if you're a Twilight Zone fan then you'll understand the
> ramifications of this.
> 
> Bob


Article: 105624
Subject: Re: Guided MAP/PAR in ISE
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 27 Jul 2006 12:38:05 -0400
Links: << >>  << T >>  << A >>
"Brannon" <brannonking@yahoo.com> wrote in message
news:1154014545.550301.275490@m73g2000cwd.googlegroups.com...
>
> 80% of the times I ran it, it crashed. The other 20% of the time it
> took longer than running without it.

That's exactly what I am experiencing as well!!!

/Mikhail






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