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 104075

Article: 104075
Subject: Newbie to FPGA
From: "anand" <writeanand@gmail.com>
Date: 18 Jun 2006 14:53:27 -0700
Links: << >>  << T >>  << A >>
Hi,

I am a pre-si verification engineer looking to learn HW design,
synthesis and P&R through FPGAs.  (I am already very comfortable with
Verilog, so that is not the issue, I really want to learn to
"design+synthesize+P&R" as opposed to "code in verilog").

Recently checked out Spartan dev kit, looks very affordable.
Questions:

Is this the best way to go (for a hobbyist)? I am willing to spend
couple 100 $$ on dev kits etc. Ive already downloaded the ISE Webpack
and have full access to Modelsim at work.

What books should I get for DESIGN & SYNTHESIS (again, not verilog
coding but "designing" synthesizable code with Verilog). Please suggest
books with and without an FPGA "tilt" or focus if possible.


Once you do everything and download stuff into the FPGA, how do you run
the application?
For ex, if you design a H.264 encoder (just for example), and the FPGA
already has the code downloaded after Synthesis and P&R stage, how can
I pass an example stimulus file (ie H.264 stream) to see if it works
correctly?


My grand vision is to build a H.264 encoder module in an FPGA, while
teaching myself good design AND H.264 encoding in the process.


Am I missing anything here? Anything else I should know? 

Thanks


Article: 104076
Subject: Re: Newbie to FPGA
From: "anand" <writeanand@gmail.com>
Date: 18 Jun 2006 14:58:17 -0700
Links: << >>  << T >>  << A >>
Just to add, I am already comfortable with poking around RTL and large
designs, I just havent done the design myself. (Victim of working in a
big company :-) )

Are there any more project ideas that will add value to my resume (such
as MPEG encoder/decoder etc) that I can do with an FPGA and check out
at home using a PC?
I have already started designing small modules (fifos etc, mostly
synchrounous).
Just getting into async fifo design, I still havent understood it
fully.

-Anand

anand wrote:
> Hi,
>
> I am a pre-si verification engineer looking to learn HW design,
> synthesis and P&R through FPGAs.  (I am already very comfortable with
> Verilog, so that is not the issue, I really want to learn to
> "design+synthesize+P&R" as opposed to "code in verilog").
>
> Recently checked out Spartan dev kit, looks very affordable.
> Questions:
>
> Is this the best way to go (for a hobbyist)? I am willing to spend
> couple 100 $$ on dev kits etc. Ive already downloaded the ISE Webpack
> and have full access to Modelsim at work.
>
> What books should I get for DESIGN & SYNTHESIS (again, not verilog
> coding but "designing" synthesizable code with Verilog). Please suggest
> books with and without an FPGA "tilt" or focus if possible.
>
>
> Once you do everything and download stuff into the FPGA, how do you run
> the application?
> For ex, if you design a H.264 encoder (just for example), and the FPGA
> already has the code downloaded after Synthesis and P&R stage, how can
> I pass an example stimulus file (ie H.264 stream) to see if it works
> correctly?
>
>
> My grand vision is to build a H.264 encoder module in an FPGA, while
> teaching myself good design AND H.264 encoding in the process.
>
>
> Am I missing anything here? Anything else I should know? 
> 
> Thanks


Article: 104077
Subject: Re: High speed differential to single ended
From: "vans" <svasanth@gmail.com>
Date: 18 Jun 2006 15:24:49 -0700
Links: << >>  << T >>  << A >>
Hi,

Thanks for all the replies.

> But each pixel has to shoot ten bits through the wires, as you said
> above. That is 1.5Gbps or 750MHz worst case frequency. Both your op
> amps and your FPGAs will have trouble coping with that.
>

I don't understand how its 1.5Gbps. If we have a clock freq. of 150
MHz, we are serially sending one bit every 1 / 150MHz = ~6.7ns. So this
means that there is a delay of (6.7 * 10 = 67ns) per pixel (because R,
G, B are sent in parallel). Shouldn't this be 150MBps, and not 1.5Gbps?


It seems the best course is to go with an LVDS receiver, like the ones
recommended above, but my only worry is if they can be fast enough

Thanks


Article: 104078
Subject: Re: High speed differential to single ended
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 18 Jun 2006 15:34:51 -0700
Links: << >>  << T >>  << A >>
1.65 Gbps is slightly beyond the capabilities of any general-purpose
I/O on all the FPGAs that I am aware of. Correct me if I am wrong.
But it is very easy for the dedicated mult-gigabit transceivers
available from several vendors (e.g. from Xilinx: Virtex-2Pro,
Virtex-4FX and soon Virtex-5LXT).

Peter Alfke
=============
Thomas Womack wrote:
>
> One pin-pair per colour channel, sending 8->10-encoded data at up to
> 1650Mbps.  There's one shielding wire per pair of colour channels, and
> a differential clock also.  I've no idea what the signalling protocols
> look like.
>
> Some kinds of HDTV set (as opposed to computer monitor) encrypt the
> data with a stream cipher, though that only has to run at the pixel
> rate rather than the bit rate.
>
> For the very high resolutions (2048x1536 and above), DVI goes to two
> pin-pairs per channel and so up to about 4Gbps.
> 
> Tom


Article: 104079
Subject: Re: Newbie to FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 18 Jun 2006 15:50:21 -0700
Links: << >>  << T >>  << A >>

anand wrote:
> Just getting into async fifo design, I still havent understood it
> fully.
>
Using a dual-ported RAM, most of any asynchronous FIFO design is
trivial.
But the devil is in the flags (FULL and EMPTY) which get de-activated
by the "wrong" clock.
For example: EMPTY is activated by the read clock, and of importance
only in that read clock domain, but it gets de-activated by a write
clock. There is no defined phase relationship between the two clocks.
:-(
That clock-domain crossing requires Grray-coded address counters and
some trickery to avoid (or mitigate) metastability.

Just google, and read some papers by sunburst or Xilinx/yours truly,
like XAPP051.

Peter Alfke, Xilinx


Article: 104080
Subject: Re: Newbie to FPGA
From: "anand" <writeanand@gmail.com>
Date: 18 Jun 2006 16:09:02 -0700
Links: << >>  << T >>  << A >>
Thanks Peter, I just downloaded XAPP051,

Can you (or someone else) provide some inputs on my post #1 above?
Thanks in advance.

-Anand
Peter Alfke wrote:
> anand wrote:
> > Just getting into async fifo design, I still havent understood it
> > fully.
> >
> Using a dual-ported RAM, most of any asynchronous FIFO design is
> trivial.
> But the devil is in the flags (FULL and EMPTY) which get de-activated
> by the "wrong" clock.
> For example: EMPTY is activated by the read clock, and of importance
> only in that read clock domain, but it gets de-activated by a write
> clock. There is no defined phase relationship between the two clocks.
> :-(
> That clock-domain crossing requires Grray-coded address counters and
> some trickery to avoid (or mitigate) metastability.
>
> Just google, and read some papers by sunburst or Xilinx/yours truly,
> like XAPP051.
> 
> Peter Alfke, Xilinx


Article: 104081
Subject: Re: High speed differential to single ended
From: eternal_nan@yahoo.com
Date: 18 Jun 2006 16:33:08 -0700
Links: << >>  << T >>  << A >>
Hi All,

To the OP: Silicon Image manufactures ICs that receive a serial DVI
stream and convert it
to various other formats (656 like serial stream, 12b DDR pixel data +
HSYNC + VSYNC + DE, etc.). That is probably what you need. Anyhow, DVI
is transmitted over three serial links which are 8b10b encoded, so
150MHz works out to (150MHz*3links) / 10bits = 45 MB/sec. This is not
enough for HD speeds, but is enough for some VESA defined resolutions.

Regards,
Ljubisa Bajic

Peter Alfke wrote:
> 1.65 Gbps is slightly beyond the capabilities of any general-purpose
> I/O on all the FPGAs that I am aware of. Correct me if I am wrong.
> But it is very easy for the dedicated mult-gigabit transceivers
> available from several vendors (e.g. from Xilinx: Virtex-2Pro,
> Virtex-4FX and soon Virtex-5LXT).
>
> Peter Alfke
> =============
> Thomas Womack wrote:
> >
> > One pin-pair per colour channel, sending 8->10-encoded data at up to
> > 1650Mbps.  There's one shielding wire per pair of colour channels, and
> > a differential clock also.  I've no idea what the signalling protocols
> > look like.
> >
> > Some kinds of HDTV set (as opposed to computer monitor) encrypt the
> > data with a stream cipher, though that only has to run at the pixel
> > rate rather than the bit rate.
> >
> > For the very high resolutions (2048x1536 and above), DVI goes to two
> > pin-pairs per channel and so up to about 4Gbps.
> > 
> > Tom


Article: 104082
Subject: Re: Newbie to FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 18 Jun 2006 16:39:25 -0700
Links: << >>  << T >>  << A >>
The FPGA allows you to define the internal logic of a chip. After you
complete the logic design and simulation, you pass it through the
(Xilinx) place and route tool, which generates a bitstream of a few
million bits.
You feed this bitstream (in bit-serial or byte-parallel form) into the
FPGA (various methods, all well-described), and then you have your
custom chip, as long as you keep its Vcc up !
To make it do something, you feed its inputs and observe its outputs,
just as you would with a specialized custom chip, ASIC, memory,
microprocessor etc...

Was that too simplistic?
Peter Alfke
==================
anand wrote:
> Thanks Peter, I just downloaded XAPP051,
>
> Can you (or someone else) provide some inputs on my post #1 above?
> Thanks in advance.
>
> -Anand
> Peter Alfke wrote:
> > anand wrote:
> > > Just getting into async fifo design, I still havent understood it
> > > fully.
> > >
> > Using a dual-ported RAM, most of any asynchronous FIFO design is
> > trivial.
> > But the devil is in the flags (FULL and EMPTY) which get de-activated
> > by the "wrong" clock.
> > For example: EMPTY is activated by the read clock, and of importance
> > only in that read clock domain, but it gets de-activated by a write
> > clock. There is no defined phase relationship between the two clocks.
> > :-(
> > That clock-domain crossing requires Grray-coded address counters and
> > some trickery to avoid (or mitigate) metastability.
> >
> > Just google, and read some papers by sunburst or Xilinx/yours truly,
> > like XAPP051.
> > 
> > Peter Alfke, Xilinx


Article: 104083
Subject: Re: High speed differential to single ended
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 18 Jun 2006 17:03:00 -0700
Links: << >>  << T >>  << A >>
This is getting ever more confusing.

I think we agreed already that there are roughly 2 million pixel x 60
Hz, roughly 150 million pixel per second.

There are three channels, one per color, and each pixel color is
represented by 8 serial bits. Encoded with 8B/10B this requires 10
bits. 150 million pixel times 10 bits = 1.5 Gigabits per second. And
this obviously three times, once per color.
Inside the FPGA, the pixel color is represented as 8 bits in parallel,
which gets us back to a managable 150 MHz and a total of 24 chanels.
The serial bit rate is too high (by a factor 2) for general purpose
I/O, therefore, as I claimed, only dedicated inputs can handle such a
high bitrate of 1.5 Gbps. But if you are willing to dedicate a total of
24 input pins (plus clocks), then the frequency is only 150 MHz, which
any modern chip handles easily.

The total traffic is roughly 4 gigabits per second. There is no way
around that, unless you use compression.

Can we all agree on this?
Peter Alfke, Xilinx Applications
================


Article: 104084
Subject: Re: Newbie to FPGA
From: Tim Wescott <tim@seemywebsite.com>
Date: Sun, 18 Jun 2006 17:31:38 -0700
Links: << >>  << T >>  << A >>
anand wrote:

> Hi,
> 
> I am a pre-si verification engineer looking to learn HW design,
> synthesis and P&R through FPGAs.  (I am already very comfortable with
> Verilog, so that is not the issue, I really want to learn to
> "design+synthesize+P&R" as opposed to "code in verilog").
> 
> Recently checked out Spartan dev kit, looks very affordable.
> Questions:
> 
> Is this the best way to go (for a hobbyist)? I am willing to spend
> couple 100 $$ on dev kits etc. Ive already downloaded the ISE Webpack
> and have full access to Modelsim at work.

Probably as good as any.
> 
> What books should I get for DESIGN & SYNTHESIS (again, not verilog
> coding but "designing" synthesizable code with Verilog). Please suggest
> books with and without an FPGA "tilt" or focus if possible.
> 
I use Thomas & Moorby's "The Verilog Hardware Description Language", 
which is mostly about Verilog but sprinkles in guidance for 
synthesizable designs.
> 
> Once you do everything and download stuff into the FPGA, how do you run
> the application?

You don't.  What's in an FPGA isn't an "application" and it doesn't 
"run" in the sense that an application does.  Once you've _configured_ 
the FPGA you let it loose, and off it goes doing whatever you coded it 
to do.

> For ex, if you design a H.264 encoder (just for example), and the FPGA
> already has the code downloaded after Synthesis and P&R stage, how can
> I pass an example stimulus file (ie H.264 stream) to see if it works
> correctly?
> 
You wouldn't really run a stimulus file through it -- you'd need to use 
(or generate) an appropriate stream to run in real life to wiggle the 
inputs pins on your FPGA.
> 
> My grand vision is to build a H.264 encoder module in an FPGA, while
> teaching myself good design AND H.264 encoding in the process.
> 
> 
> Am I missing anything here? Anything else I should know? 
> 
> Thanks
> 
You might want to start out a bit simpler -- I'd suggest blinking the 
lights, then maybe blinking the lights under the control of the switches.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 104085
Subject: Re: Floppy to FPGA?
From: Mark McDougall <markm@vl.com.au>
Date: Mon, 19 Jun 2006 10:54:26 +1000
Links: << >>  << T >>  << A >>
fslearner wrote:

> Can anybody comment on the
> feasibility of this project and perhaps point me to some existing VHDL
> code? Otherwise, does anyone have any other feasible ideas?

As others have concurred, definitely feasible. I have implemented a 
read-only version of a WD1793 FDC in VHDL which interfaces to a SPI 
serial flash device rather than a floppy drive.

Some in this thread have talked about drive pules and MFM encoding etc 
etc - that's *way* too low-level for your requirements. There is no need 
to emulate operation at the physical encoding level - in fact you'd be 
silly to do so! You need only emulate the register level interface of 
the controller and implement a means to store the data for a disk image.

Depending on the actual controller, you *may* need to store a little 
more info than the actual sector data - for example I needed to flag 
which sectors had a non-standard data address mark. However considering 
that you don't need to read the 'images' back on the same controller, 
you can probably get away with fudging it.

The size of your emulated floppy image is probably still going to be 
constrained by the size of a floppy disk - your imaging device still 
needs to 'see' a formatted file system and is only expecting a 
floppy-sized disk. However, since you can 'suck' the image off your 
emulated drive immediately I'd imagine you could have an arrangement 
such that as soon as an image is written, it is transferred to your PC 
and then deleted from the emulated disk?!?

I started my implementation with a micro (soft IP core) rather than VHDL 
code. I had an interrupt firing off a write to the emulated disk 
controller 'command' register. It was sort-of working but wasn't quite 
quick enough for what I needed, so I opted for a VHDL design. However, 
I'm sure there's plenty of small micros around fast enough to do the job.

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: 104086
Subject: --.-Low Cost High quality pcb prototype and Assembly manufacturer(CHINA).
From: "t2531998@126.com" <t2531998@126.com>
Date: 18 Jun 2006 19:00:13 -0700
Links: << >>  << T >>  << A >>

We are manufacture low cost, high quality PCB prototypes in China.

Silk masks are produced for the same price

Send us a PCB file and we will reply promptly with a quote.

We can assemble components for your company.

if any question, Please email us with your questions.

We sell high quality HDI PCB's.

accept delivery times are prompt.(quick turn)

We can supply color PCBs board(Example: Blue,
Black,Red,Green,White,yellow.)

Mail: njpcb@vip.163.com or sales@njpcb.com


E-mail pcb files to us and we will provide a prompt quote.


We sebd PCB via DHL or UPS ( Approx 1 day from Chins to the USA)


Product Name: Printed Circuit BoardPlace of Origin: ChinaFeatures:
1) Surface finish: hot air solder leveling, entice, immersion gold,
carbon ink, gold finger, peelable mask
2) PCB file format: protel,powerpcb,Gerber file,Engle....
3) Profile: routing, punching, V-Cut, chamfered
4) Number of layers for mass production: 2 - 12
5) Finished copper weight from .25 to 3oz
6) Minimum finished hole size .006"
7) Min. trace .004" - Min. space .004"
8) Max. panel size: 18" x 24"
9) Printed circuit board final thickness from .016" to .125"
10)soldermask /Legend in a variety of colors
(Green,White,Black,Yellow,Red..)
11)operating costs (10 pieces ):  2 layers( about 0.048$/inch)  4
layers(about 0.096$/inch)

Lead times:  2 layers( 1 days, 3 days, 5 days) Ships next day.
             4 layers( 2 days, 5 days, 7 days)
             6 layers( 3 days, 5 days, 8 days)


Min Qty 3pcs.
Web:www.n j p c b.c o m
mail: sales@n j p c b.c o m
Contact Person:  Mr. Ding JiaBao

Website:  http://www.njpcb.com
E-mail:   njpcb@vip.163.com or sales@njpcb.com

Any advice will be greatly appreciated!

if any question,Please send e-mail to us,we will reply as soon.


Article: 104087
Subject: Re: Newbie to FPGA
From: "anand" <writeanand@gmail.com>
Date: 18 Jun 2006 19:32:03 -0700
Links: << >>  << T >>  << A >>
>You wouldn't really run a stimulus file through it -- you'd need to use
>(or generate) an appropriate stream to run in real life to wiggle the
>inputs pins on your FPGA.

Thanks Tim. So, if I had to test the application in real life, then I
have to stimulate the input pins, correct? So, how do I go about
testing on the FPGA as to whether the design actually works in real
life (not in simulation)?  Assume I have a H.264 stream that I can use.

So in the dev board kit they have flash memory, I guess I can probably
load the flash memory with the stimulus stream. But question is, how do
I make it wiggle the appropriate pins of the FPGA itself, and how do I
collect the output to verify it?



Tim Wescott wrote:
> anand wrote:
>
> > Hi,
> >
> > I am a pre-si verification engineer looking to learn HW design,
> > synthesis and P&R through FPGAs.  (I am already very comfortable with
> > Verilog, so that is not the issue, I really want to learn to
> > "design+synthesize+P&R" as opposed to "code in verilog").
> >
> > Recently checked out Spartan dev kit, looks very affordable.
> > Questions:
> >
> > Is this the best way to go (for a hobbyist)? I am willing to spend
> > couple 100 $$ on dev kits etc. Ive already downloaded the ISE Webpack
> > and have full access to Modelsim at work.
>
> Probably as good as any.
> >
> > What books should I get for DESIGN & SYNTHESIS (again, not verilog
> > coding but "designing" synthesizable code with Verilog). Please suggest
> > books with and without an FPGA "tilt" or focus if possible.
> >
> I use Thomas & Moorby's "The Verilog Hardware Description Language",
> which is mostly about Verilog but sprinkles in guidance for
> synthesizable designs.
> >
> > Once you do everything and download stuff into the FPGA, how do you run
> > the application?
>
> You don't.  What's in an FPGA isn't an "application" and it doesn't
> "run" in the sense that an application does.  Once you've _configured_
> the FPGA you let it loose, and off it goes doing whatever you coded it
> to do.
>
> > For ex, if you design a H.264 encoder (just for example), and the FPGA
> > already has the code downloaded after Synthesis and P&R stage, how can
> > I pass an example stimulus file (ie H.264 stream) to see if it works
> > correctly?
> >
> You wouldn't really run a stimulus file through it -- you'd need to use
> (or generate) an appropriate stream to run in real life to wiggle the
> inputs pins on your FPGA.
> >
> > My grand vision is to build a H.264 encoder module in an FPGA, while
> > teaching myself good design AND H.264 encoding in the process.
> >
> >
> > Am I missing anything here? Anything else I should know?
> >
> > Thanks
> >
> You might want to start out a bit simpler -- I'd suggest blinking the
> lights, then maybe blinking the lights under the control of the switches.
>
> --
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>
> Posting from Google?  See http://cfaj.freeshell.org/google/
>
> "Applied Control Theory for Embedded Systems" came out in April.
> See details at http://www.wescottdesign.com/actfes/actfes.html


Article: 104088
Subject: Re: --.-Low Cost High quality pcb prototype and Assembly manufacturer(CHINA).
From: Stephen Williams <spamtrap@icarus.com>
Date: Sun, 18 Jun 2006 20:04:06 -0700
Links: << >>  << T >>  << A >>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

t2531998@126.com wrote:
> [spam spewage]

Is there a way to filter this spam out? It appears that this
guy/gal/other is morphing as he/she/it continues to spam, and
I'm not seeing an obvious filter to use.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFElhQmrPt1Sc2b3ikRAp89AJwIhggxDz1G8S8DatzIotR64z6dgACgymQw
Q7U5QiHMsSYZ4jTxLurDzW0=
=ny9J
-----END PGP SIGNATURE-----

Article: 104089
Subject: Re: High speed differential to single ended
From: John_H <johnhandwork@mail.com>
Date: Mon, 19 Jun 2006 04:05:09 GMT
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> This is getting ever more confusing.
> 
> I think we agreed already that there are roughly 2 million pixel x 60
> Hz, roughly 150 million pixel per second.
> 
> There are three channels, one per color, and each pixel color is
> represented by 8 serial bits. Encoded with 8B/10B this requires 10
> bits. 150 million pixel times 10 bits = 1.5 Gigabits per second. And
> this obviously three times, once per color.
> Inside the FPGA, the pixel color is represented as 8 bits in parallel,
> which gets us back to a managable 150 MHz and a total of 24 chanels.
> The serial bit rate is too high (by a factor 2) for general purpose
> I/O, therefore, as I claimed, only dedicated inputs can handle such a
> high bitrate of 1.5 Gbps. But if you are willing to dedicate a total of
> 24 input pins (plus clocks), then the frequency is only 150 MHz, which
> any modern chip handles easily.
> 
> The total traffic is roughly 4 gigabits per second. There is no way
> around that, unless you use compression.
> 
> Can we all agree on this?
> Peter Alfke, Xilinx Applications
> ================

What might not be communicated so far:  while DVI can go up to a 165 MHz 
pixel clock limit (without going to a dual-DVI link) the pixel clock 
doesn't have to go that fast.  If one is using a slow, small LCD one can 
get by with rates that don't exceed 300 MB/s/channel.

I'm not aware (though I haven't done deep research) that there's a lower 
limit on the pixel clock.

Article: 104090
Subject: Re: --.-Low Cost High quality pcb prototype and Assembly manufacturer(CHINA).
From: John_H <johnhandwork@mail.com>
Date: Mon, 19 Jun 2006 04:09:42 GMT
Links: << >>  << T >>  << A >>
Doesn't the "Sender" always contain "@126.com"?


Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> t2531998@126.com wrote:
>> [spam spewage]
> 
> Is there a way to filter this spam out? It appears that this
> guy/gal/other is morphing as he/she/it continues to spam, and
> I'm not seeing an obvious filter to use.
> 
> - --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com           But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFElhQmrPt1Sc2b3ikRAp89AJwIhggxDz1G8S8DatzIotR64z6dgACgymQw
> Q7U5QiHMsSYZ4jTxLurDzW0=
> =ny9J
> -----END PGP SIGNATURE-----

Article: 104091
Subject: Re: --.-Low Cost High quality pcb prototype and Assembly manufacturer(CHINA).
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 19 Jun 2006 05:58:35 GMT
Links: << >>  << T >>  << A >>
On Sun, 18 Jun 2006 20:04:06 -0700, Stephen Williams <spamtrap@icarus.com> wrote:
>
>Is there a way to filter this spam out? It appears that this
>guy/gal/other is morphing as he/she/it continues to spam, and
>I'm not seeing an obvious filter to use.


I think it is time for everybody who uses this news group to
send a short email to njpcb@vip.163.com or sales@njpcb.com

and ask nicely for them to stop spamming this news group.

I certainly hope no-one has given them any business, as this
only encourages this obnoxious behaviour.


Article: 104092
Subject: Re: Floppy to FPGA?
From: ghelbig@lycos.com
Date: 18 Jun 2006 23:00:23 -0700
Links: << >>  << T >>  << A >>
fslearner wrote:
> ghelbig@lycos.com wrote:
> > Odds are, this equipment is way too old to have a 3.5" floppy -or- an
> > IDE port.  Most likely, it's a 5.25" inch drive, mayby FAT12 360K,
> > mayby not.
> >
>
> I suppose I should have mentioned that the drive in question is
> actually a 3.5" floppy. I'm not sure whether there's a spare IDE port
> however. It also runs some DOS variant.

In that case...  What type of bus is in the system?  If you can drop
another card into the system, hyou have all kinds of options.

There are USB drivers for DOS.  If you can get that far, your choices
open up significantly.


Article: 104093
Subject: Re: Anyone get a Pictiva OLED to work?
From: "Bluespace Technologies" <bluespace@rogers.com>
Date: Mon, 19 Jun 2006 02:01:47 -0400
Links: << >>  << T >>  << A >>
Antti,

Is there a method of simply using the FPGA to control the OLED completely? I 
use my FPGA as a GPS-like DSP and want the output coordinate data displayed 
directly onto the OLED. Currently I send my data to a host computer to 
present on the screen, through the RS232 link. I want to remove all that and 
use only the OLED already in the FPGA board. This sounds simple but the code 
for this "simple" application is not straight forward, or I am missing big 
chunks of grey matter. I don't want to resort to C++ code or buy other kits 
to make this work. My guess is that OSRAM wants to force us to buy their 
RS-030 reference design kit to get started.

-Andrew

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1150569349.569369.323620@h76g2000cwa.googlegroups.com...
> Eric Smith schrieb:
>
>> "Bluespace Technologies" <bluespace@rogers.com> writes:
>> > I'm trying to use the sample pictiva VHDL code from Avnet to drive a 
>> > mini
>> > OLED (OSRAM Pictiva 128x64 pixel) on their test board, to get anything
>> > presented (numerical data) on the screen. Has anyone got this device to
>> > work, using sample code or other?
>>
>> I haven't tried yet.  I am somewhat pissed off that the datasheet on the
>> controller chip in the module is apparently nearly impossible to obtain, 
>> and
>> the data sheet on the module doesn't give the details of the interface 
>> other
>> than electrical parameters.
>
> datasheet for the controller IC
>
> http://www.mikrocontroller.net/attachment.php/347504/Treiber_IC-SSD0323_OLED_128x64_GELB.pdf
>
> its all on the net :)
>
> Antti
> 



Article: 104094
Subject: Re: Anyone get a Pictiva OLED to work?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 18 Jun 2006 23:58:50 -0700
Links: << >>  << T >>  << A >>
Bluespace Technologies schrieb:

> Antti,
>
> Is there a method of simply using the FPGA to control the OLED completely? I
> use my FPGA as a GPS-like DSP and want the output coordinate data displayed
> directly onto the OLED. Currently I send my data to a host computer to
> present on the screen, through the RS232 link. I want to remove all that and
> use only the OLED already in the FPGA board. This sounds simple but the code
> for this "simple" application is not straight forward, or I am missing big
> chunks of grey matter. I don't want to resort to C++ code or buy other kits
> to make this work. My guess is that OSRAM wants to force us to buy their
> RS-030 reference design kit to get started.
>
> -Andrew

there is no need to buy any osram kit, the oled interface is very
simple, you can easlily
control it with an FPGA, but you need something to handle the protocol
in the FPGA
and that is easier todo with some kind of soft-core processor just
connect the oled
to some kind of "GPIO" port of the softcore and write the control
program in any language
supported by that softcore. Sure the control could be done without the
softcore processor
but then you need a complex statemachine what is far more difficult to
design.

Antti


Article: 104095
Subject: Re: High speed differential to single ended
From: "Antti" <Antti.Lukats@xilant.com>
Date: 19 Jun 2006 00:01:12 -0700
Links: << >>  << T >>  << A >>
John_H schrieb:

> Peter Alfke wrote:
> > This is getting ever more confusing.
[]
> I'm not aware (though I haven't done deep research) that there's a lower
> limit on the pixel clock.

"pixel clock below 22.5MHz for a duration of 1s is to be considered
IDLE (link down)"

this sounds like lower limit?

Antti


Article: 104096
Subject: Re: High speed differential to single ended
From: "Antti" <Antti.Lukats@xilant.com>
Date: 19 Jun 2006 00:20:46 -0700
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:

> This is getting ever more confusing.
>
> I think we agreed already that there are roughly 2 million pixel x 60
> Hz, roughly 150 million pixel per second.
>
> There are three channels, one per color, and each pixel color is
> represented by 8 serial bits. Encoded with 8B/10B this requires 10
> bits. 150 million pixel times 10 bits = 1.5 Gigabits per second. And
> this obviously three times, once per color.
> Inside the FPGA, the pixel color is represented as 8 bits in parallel,
> which gets us back to a managable 150 MHz and a total of 24 chanels.
> The serial bit rate is too high (by a factor 2) for general purpose
> I/O, therefore, as I claimed, only dedicated inputs can handle such a
> high bitrate of 1.5 Gbps. But if you are willing to dedicate a total of
> 24 input pins (plus clocks), then the frequency is only 150 MHz, which
> any modern chip handles easily.
>
> The total traffic is roughly 4 gigabits per second. There is no way
> around that, unless you use compression.
>
> Can we all agree on this?
> Peter Alfke, Xilinx Applications
> ================

Hi Peter,

I was about to reply to one of your earlier posts but it was nice
weather and so I went to "English Garden" instead with children. But
you have been busy responding in this thread :)

DVI clock requirement for PLL lock in receiver 25MHz up to supported
max (165MHz), one "symbol" is 10 bits those we have bit rate of 250MB/s
to 1.65MB/s per differential pair, the electrical levels are
differential, DC coupled, with termination to 3.3V transmitter
differential swing 500mV (400-600mv) the swing is "centered" half down
from termination, so the single ended signal would swing from 3.3V
down.

To my knowledge FPGA IO standards do not include and option that would
support this signalling directly.

Input differential margin > 150mV , ok that is compatible to FPGA LVDS
inputs if they work at around 3.3V DC levels then a 50ohm termination
to 3.3V and FPGA LVDS input could work.

DVI clock is at 'symbol rate' those we need a PLL to lock at 10X the
clock. Next thing is that we need per line clock lock to the data
stream (a digital delay lock) and per line descew correction.

All of the above is just that much of trouble that it makes in not
reasonable even to think about implementing the DVI in FPGA without
using a proper DVI receiver or transmitter IC.

CH7301 has 12 bit DDR like data bus so it requires for FPGA
communication

12 data (SDR or DDR)
1 (or 2) for pixeld clock (can be single ended or differential)
5 for control
DE
HSYNC
VSYNC
SDA - i2c for parameter setting
SCL

the chip has internal register to adjust the clock edge in order to
sample the data lines at correct phase relation.

the chip costs some 8 EUR, I dont have pricing on DVI receiver but I
belive those prices also be in range of 10EUR. As an extra the CH7301
also includes Analog RGB DACs so you can uses either DVI or analog
monitor!

I hope the above explains why I a said in my first posting in this
thread: "NO WAY".

I agree that with some really clever tricks and some ommissions some
DVI things could be done directly in the FPGA using FPGA I/O pins, but
it really doesnt seem like reasonable thing todo. Unless someone has
months and months of time he wishes to waste.

Antti


Article: 104097
Subject: Re: Anyone get a Pictiva OLED to work?
From: "Marco" <marco@marylon.com>
Date: 19 Jun 2006 00:31:02 -0700
Links: << >>  << T >>  << A >>
Hi all,
I'm also working with a Pictiva Oled with my Spartan3 and I was going
to ask you about the best way to handle this display. From what I'm
reading it seems easy to implement its control with something like
Microblaze on your FPGA, while pretty harder without it and just VHDL
code. I never done anything with Microblaze so far and at this point I
don't know which way will be easier and shorter: keep VHDLing or moving
to the never-used Microblaze or PicoBlaze if the latter would do that
well.
Thanks,
Marco



Antti ha scritto:

> Bluespace Technologies schrieb:
>
> > Antti,
> >
> > Is there a method of simply using the FPGA to control the OLED completely? I
> > use my FPGA as a GPS-like DSP and want the output coordinate data displayed
> > directly onto the OLED. Currently I send my data to a host computer to
> > present on the screen, through the RS232 link. I want to remove all that and
> > use only the OLED already in the FPGA board. This sounds simple but the code
> > for this "simple" application is not straight forward, or I am missing big
> > chunks of grey matter. I don't want to resort to C++ code or buy other kits
> > to make this work. My guess is that OSRAM wants to force us to buy their
> > RS-030 reference design kit to get started.
> >
> > -Andrew
>
> there is no need to buy any osram kit, the oled interface is very
> simple, you can easlily
> control it with an FPGA, but you need something to handle the protocol
> in the FPGA
> and that is easier todo with some kind of soft-core processor just
> connect the oled
> to some kind of "GPIO" port of the softcore and write the control
> program in any language
> supported by that softcore. Sure the control could be done without the
> softcore processor
> but then you need a complex statemachine what is far more difficult to
> design.
> 
> Antti


Article: 104098
Subject: Re: Anyone get a Pictiva OLED to work?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 19 Jun 2006 00:35:41 -0700
Links: << >>  << T >>  << A >>
Marco schrieb:

> Hi all,
> I'm also working with a Pictiva Oled with my Spartan3 and I was going
> to ask you about the best way to handle this display. From what I'm
> reading it seems easy to implement its control with something like
> Microblaze on your FPGA, while pretty harder without it and just VHDL
> code. I never done anything with Microblaze so far and at this point I
> don't know which way will be easier and shorter: keep VHDLing or moving
> to the never-used Microblaze or PicoBlaze if the latter would do that
> well.
> Thanks,
> Marco

It all depends - if you have already a MicroBlaze in the FPGA then just
take the
pictive OPB IP Core and use it, if you dont then well you can choose
any softcore
that pleases you, you can use PicoBlaze or if you are more familiar
with PIC,AVR,8051
you can use those as well as fpga softcore. If resource use is at
premium then PicoBlaze
is very small.

Antti


Article: 104099
Subject: Re: High speed differential to single ended
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 19 Jun 2006 09:07:06 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <1150669489.775416.324560@f6g2000cwb.googlegroups.com>,
vans <svasanth@gmail.com> wrote:
>Hi,
>
>Thanks for all the replies.
>
>> But each pixel has to shoot ten bits through the wires, as you said
>> above. That is 1.5Gbps or 750MHz worst case frequency. Both your op
>> amps and your FPGAs will have trouble coping with that.
>>
>
>I don't understand how its 1.5Gbps. If we have a clock freq. of 150
>MHz, we are serially sending one bit every 1 / 150MHz = ~6.7ns.

We have a *pixel clock* of 150MHz, so have to send a whole pixel,
which thanks to the transmission encoding takes ten bits, on each of
the three colour channels, every 6.7ns; that is, the channel frequency
is 1500Mbps.

I don't know whether the 'TMDS Clock' differential pair on the DVI
connector oscillates once per pixel or once per bit; my guess is once
per pixel, with quite complicated clock-recovery circuitry at the
other end of the link to recover the bit clock.

Tom



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