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 97225

Article: 97225
Subject: Addressing BRAM in a V2 pro
From: "Mich" <michiel.vanderlinden@gmail.com>
Date: 19 Feb 2006 05:49:34 -0800
Links: << >>  << T >>  << A >>
Hi all,

I'm designing a IP core for a Virtex 2 pro board. This IP need to store
data in BRAM. I have been searching how I can adress the BRAM with my
IP but I haven't found it.
Can anyone tell me how you can do this?

Thanks
Mich


Article: 97226
Subject: help with VGA timings
From: "Jordi" <a80x86@hotmail.com>
Date: 19 Feb 2006 06:02:13 -0800
Links: << >>  << T >>  << A >>
Hi,
I'm new in fpgas.I've been researching about vga timings for a few
days, but all information I've found it's confusing. I will try to
explain what I've learn:

HS,VS signals are active low. HS tells the monitor to begin a new line,
VS tells the monitor to begin a new frame. Before activate HS ,monitor
must be in blanking mode (front porch),before draw another line monitor
must leave blanking mode (back porch). The same for VS. There is an
active time to draw all line pixels.

I'm correct?
I don't understand  timing.
For example if back porch takes 4us and active time takes 25 us in a
640x480 screen

Is the monitor expecting this timings? I mean , if I stay 8 useconds in
back porch will the monitor wait for me? , or will it begin to draw the
line after 4us?

Is the monitor reading RGB data every (25us/640)?

I've read some timings in
http://www.epanorama.net/documents/pc/vga_timing.html
Thanks ins advance,

Jordi


Article: 97227
Subject: Re: MontaVista Linux and Virtex-II & 4
From: Sylvain Munaut <com.246tNt@tnt>
Date: Sun, 19 Feb 2006 15:06:27 +0100
Links: << >>  << T >>  << A >>
Rainer Buchty wrote:
> In article <43f849af$0$2132$ba620e4c@news.skynet.be>,
>  Sylvain Munaut <com.246tNt@tnt> writes:
> |> Paul Hartke wrote:
> |> > No, the PowerPC405 caches in the current Xilinx FPGAs are not cache
> |> > coherent and so do not support SMP.  
> |> 
> |> I don't really get the relation between the two facts ... The OS could
> |> enforce coherency in software, by forcing a cache flush during task
> |> switching I think ...
> 
> The idea of having caches also means that they are transparent so that you
> do *not* need any sort of special treatment by the programmer or operating
> system.

Well, there are quite a few CPU where you need to enfore coherency by
hand when using DMA for example (there is even a flag for not coherent
cache cpu in the kernel) ...


> Besides, flushing with task switching wouldn't help as memory write accesses 
> will occur independently from task switches, so your OS would need to keep 
> track of memory accesses of all CPUs in your SMP system to block reads to 
> "dirty" addresses until they have been written back by the "dirtying" CPU, 
> i.e. the OS would have to establish a cache coherency protocol entirely in 
> software and without typical hardware assist as required for cache coherency
> protocols in hardware like MESI.

I don't get that sorry ... (note that you may be right, i'm just trying
to understand here)
I'm not that familiar with SMP but here is how it goes for me :
Processes have two kind of writable memory zones, either private to the
process or shared between several processes.

 * For independent address space, since the task will run only on a CPU
at a time, cache problem only occurs when a task is stopped on one cpu
and launched on the other. So just after stopping the task, the cpu
should flush it's cache so that if the task is launched on the other
cpu, the other has access to up-to-date memory.
 * For shared zone between processes, there is no problem either. While
the two processes are running simultaneously, no problem can occur
because the processes must handle the synchronisation themselves even on
cache coherent system (by semaphore, or flag in memory, whatever ...).
And when only one is running, the situation is similar to the
independent zones.


Sylvain

Article: 97228
Subject: FPGA Board Competition
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 19 Feb 2006 14:17:50 -0000
Links: << >>  << T >>  << A >>
In addition to the competition we are running currently running we are also 
running one in conjuction with Components In Electronics magazine. Prize is 
a special version RS1-1500 Raggedstone1. Details are in the forthcoming 
March issue. Not out yet but coming soon. Their website is 
http://www.cieonline.co.uk/.

John Adair
Enterpoint Ltd. - Taking Design to the Limit and Beyond.
http://www.enterpoint.co.uk



Article: 97229
Subject: Re: help with VGA timings
From: Sylvain Munaut <com.246tNt@tnt>
Date: Sun, 19 Feb 2006 15:22:36 +0100
Links: << >>  << T >>  << A >>
Jordi wrote:
> Hi,
> I'm new in fpgas.I've been researching about vga timings for a few
> days, but all information I've found it's confusing. I will try to
> explain what I've learn:
> 
> HS,VS signals are active low. HS tells the monitor to begin a new line,
> VS tells the monitor to begin a new frame. Before activate HS ,monitor
> must be in blanking mode (front porch),before draw another line monitor
> must leave blanking mode (back porch). The same for VS. There is an
> active time to draw all line pixels.
> 
> I'm correct?

HS & VS are not necessarly active low, it depends of the mode. Note that
all recent monitor I tried absolutly didn't care about polarity and
locked what ever I used ...

You have :
 * Front porch : Sync signal is not active, video signal is at blanking
level
 * Sync : Sync signal is active, video signal is at blanking level
 * Back porch : Sync signal is not active, video signal is at blanking level
 * Active video : Sync signal is not active, video signal is whatever
you need to display

and that's for both h & v sync.


> I don't understand  timing.
> For example if back porch takes 4us and active time takes 25 us in a
> 640x480 screen
> 
> Is the monitor expecting this timings? I mean , if I stay 8 useconds in
> back porch will the monitor wait for me? , or will it begin to draw the
> line after 4us?
> 
> Is the monitor reading RGB data every (25us/640)?

The monitors try to "lock" onto the input signal ... depending on the
monitor a particular signal might be recognized or not ... The only way
to ensure it's gonna be recognized by all monitor is to use a "standard"
timing. If it's just for experimentation, just try ... it might just
work ...


	Sylvain

Article: 97230
Subject: FPGA - software or hardware?
From: "Hub van de Bergh" <hub_antispam@hetnet.nl>
Date: Sun, 19 Feb 2006 15:58:45 +0100
Links: << >>  << T >>  << A >>
Does a VHDL programmed FPGA concern software or hardware?

As usual also this issue can be approached from different viewpoints.
One viewpoint can be the realization process,
Another viewpoint can be blackbox testing of the programmed FPGA device,
whether or not 100 % coverage can be achieved.
You will certainly be able to add your own viewpoints and your personal
opinion to this question.
Does a VHDL programmed FPGA concern software or hardware? Should software
engineering methodologies be applied or is it more likely application of
switching theory and logical design or .....
And what about design verification & validation?
What do you think?

www.hvdb.tk



Article: 97231
Subject: Re: help with VGA timings
From: Paul Hartke <phartke@Stanford.EDU>
Date: Sun, 19 Feb 2006 08:34:59 -0800
Links: << >>  << T >>  << A >>
Another good resource is http://www.xess.com/appnotes/vga.pdf

Paul

Jordi wrote:
> 
> Hi,
> I'm new in fpgas.I've been researching about vga timings for a few
> days, but all information I've found it's confusing. I will try to
> explain what I've learn:
> 
> HS,VS signals are active low. HS tells the monitor to begin a new line,
> VS tells the monitor to begin a new frame. Before activate HS ,monitor
> must be in blanking mode (front porch),before draw another line monitor
> must leave blanking mode (back porch). The same for VS. There is an
> active time to draw all line pixels.
> 
> I'm correct?
> I don't understand  timing.
> For example if back porch takes 4us and active time takes 25 us in a
> 640x480 screen
> 
> Is the monitor expecting this timings? I mean , if I stay 8 useconds in
> back porch will the monitor wait for me? , or will it begin to draw the
> line after 4us?
> 
> Is the monitor reading RGB data every (25us/640)?
> 
> I've read some timings in
> http://www.epanorama.net/documents/pc/vga_timing.html
> Thanks ins advance,
> 
> Jordi

Article: 97232
Subject: Re: FPGA - software or hardware?
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Sun, 19 Feb 2006 17:00:26 GMT
Links: << >>  << T >>  << A >>
On Sun, 19 Feb 2006 15:58:45 +0100, "Hub van de Bergh"
<hub_antispam@hetnet.nl> wrote:

>Does a VHDL programmed FPGA concern software or hardware?
>
>As usual also this issue can be approached from different viewpoints.
>One viewpoint can be the realization process,
>Another viewpoint can be blackbox testing of the programmed FPGA device,
>whether or not 100 % coverage can be achieved.
>You will certainly be able to add your own viewpoints and your personal
>opinion to this question.
>Does a VHDL programmed FPGA concern software or hardware? Should software
>engineering methodologies be applied or is it more likely application of
>switching theory and logical design or .....
>And what about design verification & validation?
>What do you think?

Essay question for homework?

-- 
Rich Webb   Norfolk, VA

Article: 97233
Subject: Re: FPGA - software or hardware?
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Sun, 19 Feb 2006 09:19:30 -0800
Links: << >>  << T >>  << A >>
On Sun, 19 Feb 2006 15:58:45 +0100, "Hub van de Bergh"
<hub_antispam@hetnet.nl> wrote:

>Does a VHDL programmed FPGA concern software or hardware?

If it works, it's hardware.

Bob Perlman
Cambrian Design Works

>
>As usual also this issue can be approached from different viewpoints.
>One viewpoint can be the realization process,
>Another viewpoint can be blackbox testing of the programmed FPGA device,
>whether or not 100 % coverage can be achieved.
>You will certainly be able to add your own viewpoints and your personal
>opinion to this question.
>Does a VHDL programmed FPGA concern software or hardware? Should software
>engineering methodologies be applied or is it more likely application of
>switching theory and logical design or .....
>And what about design verification & validation?
>What do you think?
>
>www.hvdb.tk
>

Article: 97234
Subject: Re: MontaVista Linux and Virtex-II & 4
From: buchty@atbode100.lrr.in.tum.de (Rainer Buchty)
Date: 19 Feb 2006 17:43:25 GMT
Links: << >>  << T >>  << A >>
In article <43f87b17$0$3812$ba620e4c@news.skynet.be>,
 Sylvain Munaut <com.246tNt@tnt> writes:
|> Well, there are quite a few CPU where you need to enfore coherency by
|> hand when using DMA for example (there is even a flag for not coherent
|> cache cpu in the kernel) ...

Yes, I also could come up with a system e.g. requiring non-cacheable memory
areas because one or more of the devices accessing the respective memory 
area is not able to support a cache coherency protocol.

No doubt that it can be done otherwise, but that's not the point.

|>  * For independent address space, since the task will run only on a CPU
|> at a time, cache problem only occurs when a task is stopped on one cpu
|> and launched on the other. So just after stopping the task, the cpu
|> should flush it's cache so that if the task is launched on the other
|> cpu, the other has access to up-to-date memory.

And why would you specifically need shared memory in this respect?

If your application / system does not require shared memory access by design
then of course you can come up with a light-weight solution like the above
where it seems like that the one task is the only one dealing with a specific
set of data.

|>  * For shared zone between processes, there is no problem either. While
|> the two processes are running simultaneously, no problem can occur
|> because the processes must handle the synchronisation themselves even on
|> cache coherent system (by semaphore, or flag in memory, whatever ...).

Ok, assume that the semaphore is placed in memory and we have a two-processor
system where each processor runs one of those two tasks.

You could of course switch off caching of that very memory area holding the
semaphore(s) and never have a problem. But also no cache for that area, i.e.
the accesses will be dog slow.

You could also, as I understand your example, trigger a flush so that whenever
one processor tries to read the semaphore, the other processor flushes the
cache line(s) holding your semaphore(s) while the reading processor waits for
that process to finish. Would work, but induces unnecessary bus load, waiting
times (the semaphore might not have been changed since the last read), and
furthermore a more or less complex communication protocol which needs to be
triggerend whenever any of the processors tries to access the shared memory
region.

The idea behind having a cache coherency protocol is to get consistency and
coherency at no extra cost on software side. The programmer (or the OS) do
not need to care about the entire process of access monitoring, stopping a 
read access on a memory region which has been dirtied by another processor, 
writing back that dirty information to memory, and restarting the read 
processor. The price for that you pay on hardware side, i.e. you require a
common, snoopable bus, some additional communication signals (3 in case of
MESI), logic to implement the light-weight protocol, and a slightly altered 
cache to hold the actual MESI state.

The idea behind MESI (or cache coherency protocols in general) is to keep 
the additional bus traffic as low as possible, i.e. accesses to memory only 
when necessary, keeping as much traffic inside the cache as possible.

Of course you could do all that also on software side using communication
methods on OS and application level. But for the price of increased 
complexity, bus traffic, and access latencies. 

Try scaling the 2-processor example up to 3, 4, or more processors.

Rainer

Article: 97235
Subject: Re: FPGA - software or hardware?
From: "JJ" <johnjakson@gmail.com>
Date: 19 Feb 2006 09:48:11 -0800
Links: << >>  << T >>  << A >>
If it ships with a EULA, it's software and likely doesn't work!

John Jakson


Article: 97236
Subject: Re: help with VGA timings
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Sun, 19 Feb 2006 19:01:52 GMT
Links: << >>  << T >>  << A >>
On a sunny day (19 Feb 2006 06:02:13 -0800) it happened "Jordi"
<a80x86@hotmail.com> wrote in
<1140357733.500121.71180@g47g2000cwa.googlegroups.com>:

>Hi,
>I'm new in fpgas.I've been researching about vga timings for a few
>days, but all information I've found it's confusing. I will try to
>explain what I've learn:
>
>HS,VS signals are active low. HS tells the monitor to begin a new line,
>VS tells the monitor to begin a new frame. Before activate HS ,monitor
>must be in blanking mode (front porch),before draw another line monitor
>must leave blanking mode (back porch). The same for VS. There is an
>active time to draw all line pixels.
>
>I'm correct?
>I don't understand  timing.
>For example if back porch takes 4us and active time takes 25 us in a
>640x480 screen
>
>Is the monitor expecting this timings? I mean , if I stay 8 useconds in
>back porch will the monitor wait for me? , or will it begin to draw the
>line after 4us?
The horizontal timebase in the monitor will be triggered by the neg sync edge,
and that is when it starts scanning.
If you make backporch (blanking) longer, you will just get a vertical black bar on
the screen.

Think of the 'monitor' as just 2 oscillators, one for H and one for V.
These are triggered by H and V, and in fact H uses PLL and likely V too.
So withing allowable syc range for a monitor you can change H and V frequency.
So look at the back and front porch as just a percentage of the time a scanline takes.
In fact these blanking areas are to prevent you to see non-linear effects in the scanning :-)
>Is the monitor reading RGB data every (25us/640)?
When the spot (still talking analog monitor) moves from left to right in that 25 uS
its intensity is set by the voltage at the input.
It has limited bandwidth though, and a limited number of pixels corresponding
to a limited number of holes in the shadowmask, so you cannot feed it 800MHz and
expect more detail ;-)

Article: 97237
Subject: Re: FPGA - software or hardware?
From: Phil Hays <Spampostmaster@comcast.net>
Date: Sun, 19 Feb 2006 11:21:50 -0800
Links: << >>  << T >>  << A >>
"Hub van de Bergh" <hub_antispam@hetnet.nl> wrote:

>Does a VHDL programmed FPGA concern software or hardware?

Both.


--
Phil Hays

Article: 97238
Subject: Re: help with VGA timings
From: Mike Harrison <mike@whitewing.co.uk>
Date: Sun, 19 Feb 2006 19:38:20 GMT
Links: << >>  << T >>  << A >>
On Sun, 19 Feb 2006 19:01:52 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:

>On a sunny day (19 Feb 2006 06:02:13 -0800) it happened "Jordi"
><a80x86@hotmail.com> wrote in
><1140357733.500121.71180@g47g2000cwa.googlegroups.com>:
>
>>Hi,
>>I'm new in fpgas.I've been researching about vga timings for a few
>>days, but all information I've found it's confusing. I will try to
>>explain what I've learn:
>>
>>HS,VS signals are active low. HS tells the monitor to begin a new line,
>>VS tells the monitor to begin a new frame. Before activate HS ,monitor
>>must be in blanking mode (front porch),before draw another line monitor
>>must leave blanking mode (back porch). The same for VS. There is an
>>active time to draw all line pixels.
>>
>>I'm correct?
>>I don't understand  timing.
>>For example if back porch takes 4us and active time takes 25 us in a
>>640x480 screen
>>
>>Is the monitor expecting this timings? I mean , if I stay 8 useconds in
>>back porch will the monitor wait for me? , or will it begin to draw the
>>line after 4us?
>The horizontal timebase in the monitor will be triggered by the neg sync edge,
>and that is when it starts scanning.
>If you make backporch (blanking) longer, you will just get a vertical black bar on
>the screen.
>
>Think of the 'monitor' as just 2 oscillators, one for H and one for V.
>These are triggered by H and V, and in fact H uses PLL and likely V too.
>So withing allowable syc range for a monitor you can change H and V frequency.
>So look at the back and front porch as just a percentage of the time a scanline takes.
>In fact these blanking areas are to prevent you to see non-linear effects in the scanning :-)
>>Is the monitor reading RGB data every (25us/640)?
>When the spot (still talking analog monitor) moves from left to right in that 25 uS
>its intensity is set by the voltage at the input.
>It has limited bandwidth though, and a limited number of pixels corresponding
>to a limited number of holes in the shadowmask, so you cannot feed it 800MHz and
>expect more detail ;-)

Something else to note - make sure that the video signal is properly blanked throughout the porch
and sync periods. Failing to do this can confuse the auto-adjust process on LCD monitors.

Article: 97239
Subject: Re: equivalent time sampling
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Sun, 19 Feb 2006 14:02:34 -0600
Links: << >>  << T >>  << A >>
Ok thanks once again for the info, think I have a better understanding of
what is going on

Jon

Article: 97240
Subject: Re: help with VGA timings
From: Sylvain Munaut <com.246tNt@tnt>
Date: Sun, 19 Feb 2006 21:18:02 +0100
Links: << >>  << T >>  << A >>
Mike Harrison wrote:
> On Sun, 19 Feb 2006 19:01:52 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
> 
> 
>>On a sunny day (19 Feb 2006 06:02:13 -0800) it happened "Jordi"
>><a80x86@hotmail.com> wrote in
>><1140357733.500121.71180@g47g2000cwa.googlegroups.com>:
>>
>>
>>>Hi,
>>>I'm new in fpgas.I've been researching about vga timings for a few
>>>days, but all information I've found it's confusing. I will try to
>>>explain what I've learn:
>>>
>>>HS,VS signals are active low. HS tells the monitor to begin a new line,
>>>VS tells the monitor to begin a new frame. Before activate HS ,monitor
>>>must be in blanking mode (front porch),before draw another line monitor
>>>must leave blanking mode (back porch). The same for VS. There is an
>>>active time to draw all line pixels.
>>>
>>>I'm correct?
>>>I don't understand  timing.
>>>For example if back porch takes 4us and active time takes 25 us in a
>>>640x480 screen
>>>
>>>Is the monitor expecting this timings? I mean , if I stay 8 useconds in
>>>back porch will the monitor wait for me? , or will it begin to draw the
>>>line after 4us?
>>
>>The horizontal timebase in the monitor will be triggered by the neg sync edge,
>>and that is when it starts scanning.
>>If you make backporch (blanking) longer, you will just get a vertical black bar on
>>the screen.
>>
>>Think of the 'monitor' as just 2 oscillators, one for H and one for V.
>>These are triggered by H and V, and in fact H uses PLL and likely V too.
>>So withing allowable syc range for a monitor you can change H and V frequency.
>>So look at the back and front porch as just a percentage of the time a scanline takes.
>>In fact these blanking areas are to prevent you to see non-linear effects in the scanning :-)
>>
>>>Is the monitor reading RGB data every (25us/640)?
>>
>>When the spot (still talking analog monitor) moves from left to right in that 25 uS
>>its intensity is set by the voltage at the input.
>>It has limited bandwidth though, and a limited number of pixels corresponding
>>to a limited number of holes in the shadowmask, so you cannot feed it 800MHz and
>>expect more detail ;-)
> 
> 
> Something else to note - make sure that the video signal is properly blanked throughout the porch
> and sync periods. Failing to do this can confuse the auto-adjust process on LCD monitors.

Also, make sure you use "strong" drivers for the lines that goes
directly to the VGA monitor. I had a "oscillating" image on a lcd
monitor because my hsync & vsync line were 12mA SLOW drivers. Using 24ma
and FAST made the problem go away ...

	Sylvain

Article: 97241
Subject: Re: Communication between FPGA and PC with ethernet
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 19 Feb 2006 16:59:45 -0600
Links: << >>  << T >>  << A >>
In article <1140181834.631440.296610@f14g2000cwb.googlegroups.com>,
 "Roggey" <Roggey@gmail.com> writes:
>Hello
>
>I have to make an connection to a FPGA-borad.
>
>http://www.celoxica.com/products/rc300/default.asp
>
>This board only supports ethernet communication with the mac-layer. Now
>I have to build an app that can send data(in my case images) to the
>board.
>
>My question is now how can i send data using the mac-layer only from a
>c++ programm.
>
>I do not think that we are using(or is possible to use) a router/switch
>between the pc and the board, we will use an pachted-ethernet-cable.

Get help from your local software/network/sysadmin geeks.

If I was doing that, I'd send UDP packets, and throw away (skip over)
the IP and UDP headers on the receiving side.

It's probably simplest if you can get a second ethernet card on
your PC.  You will probably have to setup routing and/or ARP by hand.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 97242
Subject: Re: realize pci in fpga
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 19 Feb 2006 17:03:43 -0600
Links: << >>  << T >>  << A >>

>It doesnt meat the spec thats what im saying, this area is one of the major 
>problems with PCI and 3.3v systems such as your FPGA, as i said in our 
>development boards we make sure the rest of the PCI bus meets there 
>specification and then make sure the trace lengths of the clock signal 
>either side of the bus switch is longer than your worst case by 0.5inches or 
>greater.
>This works for our systems and we have seen no problems,  making the trace 
>longer ensures you meet the set up and hold times for the rest of the bus.

Making the clock track longer gives you better setup but reduces your
hold time on data getting written to your chip.

For reads from your chip (or DMA writes), you have to make sure
your clock to out timings allow for two types of extra delay.
First is getting through the bus switch.  Second is the extra
delay because your clock is late because it is going through
the bus switch on the way in.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 97243
Subject: Re: Addressing BRAM in a V2 pro
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 19 Feb 2006 15:04:03 -0800
Links: << >>  << T >>  << A >>

Mich wrote:
> Hi all,
>
> I'm designing a IP core for a Virtex 2 pro board. This IP need to store
> data in BRAM. I have been searching how I can adress the BRAM with my
> IP but I haven't found it.
> Can anyone tell me how you can do this?
>
> Thanks
> Mich

Look at Xilinx's website for an appnote. It is not difficult to
interface with BRAM's.


Article: 97244
Subject: Re: FPGA - software or hardware?
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 19 Feb 2006 23:16:19 GMT
Links: << >>  << T >>  << A >>
On Sun, 19 Feb 2006 11:21:50 -0800, Phil Hays <Spampostmaster@comcast.net> wrote:
>"Hub van de Bergh" <hub_antispam@hetnet.nl> wrote:
>
>>Does a VHDL programmed FPGA concern software or hardware?
>
>Both.

Neither
Philip Freidin
Fliptronics

Article: 97245
Subject: Re: FPGA - software or hardware?
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 19 Feb 2006 15:19:49 -0800
Links: << >>  << T >>  << A >>

Philip Freidin wrote:
> On Sun, 19 Feb 2006 11:21:50 -0800, Phil Hays <Spampostmaster@comcast.net> wrote:
> >"Hub van de Bergh" <hub_antispam@hetnet.nl> wrote:
> >
> >>Does a VHDL programmed FPGA concern software or hardware?
> >
> >Both.
>
> Neither
> Philip Freidin
> Fliptronics

How are you guys coming up with answers?
I didn't understand the question ???

Euphemism's always throw me off...


Article: 97246
Subject: Re: FPGA - software or hardware?
From: Pleae_do_my_homework <Pleae_do_my_homework@for_me.com>
Date: Sun, 19 Feb 2006 15:22:49 -0800
Links: << >>  << T >>  << A >>
<http://www.fpga-faq.org/archives/52250.html#52253>

Article: 97247
Subject: Re: help with VGA timings
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 19 Feb 2006 15:24:24 -0800
Links: << >>  << T >>  << A >>

Sylvain Munaut wrote:
> Mike Harrison wrote:
> > On Sun, 19 Feb 2006 19:01:52 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
> >
> >
> >>On a sunny day (19 Feb 2006 06:02:13 -0800) it happened "Jordi"
> >><a80x86@hotmail.com> wrote in
> >><1140357733.500121.71180@g47g2000cwa.googlegroups.com>:
> >>
> >>
> >>>Hi,
> >>>I'm new in fpgas.I've been researching about vga timings for a few
> >>>days, but all information I've found it's confusing. I will try to
> >>>explain what I've learn:
> >>>
> >>>HS,VS signals are active low. HS tells the monitor to begin a new line,
> >>>VS tells the monitor to begin a new frame. Before activate HS ,monitor
> >>>must be in blanking mode (front porch),before draw another line monitor
> >>>must leave blanking mode (back porch). The same for VS. There is an
> >>>active time to draw all line pixels.
> >>>
> >>>I'm correct?
> >>>I don't understand  timing.
> >>>For example if back porch takes 4us and active time takes 25 us in a
> >>>640x480 screen
> >>>
> >>>Is the monitor expecting this timings? I mean , if I stay 8 useconds in
> >>>back porch will the monitor wait for me? , or will it begin to draw the
> >>>line after 4us?
> >>
> >>The horizontal timebase in the monitor will be triggered by the neg sync edge,
> >>and that is when it starts scanning.
> >>If you make backporch (blanking) longer, you will just get a vertical black bar on
> >>the screen.
> >>
> >>Think of the 'monitor' as just 2 oscillators, one for H and one for V.
> >>These are triggered by H and V, and in fact H uses PLL and likely V too.
> >>So withing allowable syc range for a monitor you can change H and V frequency.
> >>So look at the back and front porch as just a percentage of the time a scanline takes.
> >>In fact these blanking areas are to prevent you to see non-linear effects in the scanning :-)
> >>
> >>>Is the monitor reading RGB data every (25us/640)?
> >>
> >>When the spot (still talking analog monitor) moves from left to right in that 25 uS
> >>its intensity is set by the voltage at the input.
> >>It has limited bandwidth though, and a limited number of pixels corresponding
> >>to a limited number of holes in the shadowmask, so you cannot feed it 800MHz and
> >>expect more detail ;-)
> >
> >
> > Something else to note - make sure that the video signal is properly blanked throughout the porch
> > and sync periods. Failing to do this can confuse the auto-adjust process on LCD monitors.
>
> Also, make sure you use "strong" drivers for the lines that goes
> directly to the VGA monitor. I had a "oscillating" image on a lcd
> monitor because my hsync & vsync line were 12mA SLOW drivers. Using 24ma
> and FAST made the problem go away ...
>
> 	Sylvain


Also good to remember than the RGB input signals are terminated with 75
ohm resistors. So if you are building a R-2R DAC for each channel, you
may have to take that into account.


Article: 97248
Subject: Re: FPGA - software or hardware?
From: "JJ" <johnjakson@gmail.com>
Date: 19 Feb 2006 15:41:45 -0800
Links: << >>  << T >>  << A >>


Isaac Bosompem wrote:
> Philip Freidin wrote:
> > On Sun, 19 Feb 2006 11:21:50 -0800, Phil Hays <Spampostmaster@comcast.net> wrote:
> > >"Hub van de Bergh" <hub_antispam@hetnet.nl> wrote:
> > >
> > >>Does a VHDL programmed FPGA concern software or hardware?
> > >
> > >Both.
> >
> > Neither
> > Philip Freidin
> > Fliptronics
>
> How are you guys coming up with answers?
> I didn't understand the question ???
>
> Euphemism's always throw me off...

Thats because were are all pretty old and back when we were in school,
I think we did our own homework rather than posting questions into the
ether (arpanet was still in infancy).

Besides, badly asked obvious homework/essay questions are considered
sport. On the comp arch parent NG, the sport is far more brutal.
Professors should I hope monitor the relevant NGs to see who the class
slackers are. I actually had some buffoon google me & ask to do his
homework, only had to haggle the price.

Well composed serious and interesting questions do get some help though
if the homework is admitted and some effort has been made.

John Jakson
transputer guy


Article: 97249
Subject: Re: Addressing BRAM in a V2 pro
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 19 Feb 2006 16:10:40 -0800
Links: << >>  << T >>  << A >>
It is simple and straightforward, but remember that reading (as well as
writing) requires a clock.
And you must provide stable addresses a set-up time before the active
clock edge, not only for writing, but also for reading.
Peter Alfke, Xilinx, from home.




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