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 138750

Article: 138750
Subject: Xst:1710 warning problem
From: bish <bisheshkh@gmail.com>
Date: Sun, 8 Mar 2009 03:36:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I have designed a fsm to check whether data on three signal buses: y,
u and v (camera data) are in a certain given range. I can't understand
why ise9.2i shows following warnings:

WARNING:Xst:1710 - FF/Latch  <yuv_comp_0> (without init value) has a
constant value of 0 in block <color_recognition>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<yuv_comp_1> (without init value) has a constant value of 0 in block
<color_recognition>.


These warnings come up when I synthesize this module as a component of
some other module which gives inputs to it.

The simulation in modelsim works perfectly.
When I synthesize this module only, independently ,i.e without
instantiating it as component of other module;  these warnings do not
come up.

Here is the part of the code: (I have used three process model for
fsm. )

--yuv_comp is a 3-bit register.

--some concurrent assignments:

compared <= yuv_comp(2) and yuv_comp(1) and yuv_comp(0);

--y_is_inrange <=  .............. here comparision is made with input
signals.
--similar assignments for u_is_inrange and v_is_inrange


--this is a part of combinational process for state transition, there
are default assignments to
-avoid latch. Then:

case pstate is

			when idle =>
				if (new_frame = '1') then
					nstate <= update_output;
				end if;

			when update_output =>
            	nstate <= wait_linestart;

		   when wait_linestart =>
		       pixel_count_clear <= '1';
		       if (new_frame = '0') then
		           nstate <= for_u;
		       end if;

		when for_u =>
				if (new_frame = '1') then
				    nstate <= update_output;
				elsif (data_valid_in = '1') then
					nstate <= for_v;
				end if;

			when for_v =>
				if (new_frame = '1') then
				    nstate <= update_output;
				elsif (data_valid_in = '1') then
					nstate <= decision;
				end if;

			when decision =>
				if (compared = '1') then
					pixel_count_en <= '1';
				end if;
				if (new_frame = '1') then
				    nstate <= update_output;
				else
				   nstate <= for_u;
				end if;

			when others =>
				nstate <= idle;

		end case;

-- end of process for combin.

	reg_out: process(clk, reset) is
	begin
		if rising_edge(clk) then

			case pstate is

				when idle =>
					yuv_comp(2 downto 0) <= "000";

				when update_output =>
					total_pixels_in_range <= total_pixel_count;
				when for_u =>
					if(data_valid_in = '1') then
						yuv_comp(2) <= y_is_inrange;
						yuv_comp(1) <= u_is_inrange;
					end if;

				when for_v =>
					if (data_valid_in = '1') then
						yuv_comp(0) <= v_is_inrange;
					end if;

				when decision =>
					null;
				when others =>
					null;
			end case;
		end if;


Here is some part of synthesis report which seems to be ok except of
course the warnings mentioned above:

Found finite state machine <FSM_2> for signal <pstate>.
 
-----------------------------------------------------------------------
    | States             |
6                                              |
    | Transitions        |
13                                             |
    | Inputs             |
2                                              |
    | Outputs            |
6                                              |
    | Clock              | clk
(rising_edge)                              |
    | Reset              | reset
(positive)                               |
    | Reset type         |
asynchronous                                   |
    | Reset State        |
idle                                           |
    | Power Up State     |
idle                                           |
    | Encoding           |
automatic                                      |
    | Implementation     |
LUT                                            |
 
-----------------------------------------------------------------------
    Found 16-bit register for signal <total_pixels_in_range>.
    Found 16-bit up counter for signal <total_pixel_count>.
    Found 8-bit comparator greater for signal <u_is_inrange
$cmp_gt0000> created at line 87.
    Found 8-bit comparator less for signal <u_is_inrange$cmp_lt0000>
created at line 87.
    Found 8-bit comparator greater for signal <v_is_inrange
$cmp_gt0000> created at line 90.
    Found 8-bit comparator less for signal <v_is_inrange$cmp_lt0000>
created at line 90.
    Found 8-bit comparator greater for signal <y_is_inrange
$cmp_gt0000> created at line 84.
    Found 8-bit comparator less for signal <y_is_inrange$cmp_lt0000>
created at line 84.
    Found 3-bit register for signal <yuv_comp>.
    Summary:
	inferred   1 Finite State Machine(s).
	inferred   1 Counter(s).
	inferred  19 D-type flip-flop(s).
	inferred   6 Comparator(s).



*                       Advanced HDL
Synthesis                          *
=========================================================================

Analyzing FSM <FSM_2> for best encoding.
Optimizing FSM <color1_recognize/pstate> on signal <pstate[1:3]> with
gray encoding.
Optimizing FSM <color2_recognize/pstate> on signal <pstate[1:3]> with
gray encoding.
Optimizing FSM <color3_recognize/pstate> on signal <pstate[1:3]> with
gray encoding.
----------------------------
 State          | Encoding
----------------------------
 idle           | 000
 wait_linestart | 011
 update_output  | 001
 for_u          | 010
 for_v          | 110
 decision       | 111
----------------------------

Article: 138751
Subject: Dual port RAM on Spartan
From: "Mad I.D." <madid87@gmail.com>
Date: Sun, 8 Mar 2009 12:26:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello.

Why is there such a difference in occupied slices between single and
dual port RAM both same size?

16k x 1bit Single port 102% on Spartan 3 XC3S400
16k x 1bit Dual port (only dual read) is 69%

Why dual port consumes so much more logic?  I thought it will be a
little more or on the other hand,  twice more..

If someone could explain from where comes the 33% difference.

BTW: I know I can use block ram, that is not the question :)
Thank U !

Article: 138752
Subject: Re: Dual port RAM on Spartan
From: "Mad I.D." <madid87@gmail.com>
Date: Sun, 8 Mar 2009 12:38:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Another question

Why dual port RAM with two inputs (write for both address inputs on
the same clock)
 can not be synthesized? I know it won't use block RAM.

Article: 138753
Subject: Re: Dual port RAM on Spartan
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sun, 8 Mar 2009 13:44:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 8, 12:38=A0pm, "Mad I.D." <madi...@gmail.com> wrote:
> Another question
>
> Why dual port RAM with two inputs (write for both address inputs on
> the same clock)
> =A0can not be synthesized? I know it won't use block RAM.

BlockRAM is inherently dual-ported, so the second port is there for
free.
Distributed LUT-RAM is inherently single-ported, so the second port
must be provided by a second LUT.
Peter Alfke


Article: 138754
Subject: Re: Dual port RAM on Spartan
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 08 Mar 2009 21:17:44 +0000 (GMT)
Links: << >>  << T >>  << A >>
In article <317f5ab5-03f3-4445-9cc5-fbd30d47da41@e15g2000vbe.googlegroups.com>,
Mad I.D. <madid87@gmail.com> wrote:
>Another question
>
>Why dual port RAM with two inputs (write for both address inputs on
>the same clock)
> can not be synthesized? I know it won't use block RAM.

Are you doing an explicit priority encode for which data ends up in
the RAM when the two writes are to the same address?  Otherwise it
seems that it will end up with sufficiently many undefined behaviours
that I could see it being unsynthesisable.

How are you writing your RAMs?  I would be very surprised if you couldn't
synthesise something written like

always @(posedge clock) begin
 for (i=0; i<1024; i=1+i) begin
  if (address1 == i) then begin
   ram[8*i:8*i+7]=input1[0:7]
  end
  else begin
   if (address2 == i) then begin
    ram[8*i:8*i+7]=input2[0:7]
   end
  end
 end
end

though it would end up larger than something quite large

Tom


Article: 138755
Subject: Regarding to the "change in duty Cycle"
From: JSreeniv <sreenivas.jyothi@gmail.com>
Date: Sun, 8 Mar 2009 21:28:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I am presently working on Writing Test cases and Test benches.
I have a general query which makes me confusion.
I have a FPGA clock: fpga_clk = 50 MHz and its duty cycle = 50%, here
is description;
I am writing a one word data into the register and it will store in
some address after that it will start transmit using format
Manchester, and where my output is rcom_tx will get assert high..this
is the process.

If i changed my duty cycle to 40% and 60% than what can i expect on my
output does it assert high or low or tri-states.

Please give me some exposure on this confusion, and suggestions.

J.Sreeni,
Moog India Technology Center(Moog,Inc-USA)

Article: 138756
Subject: Re: Spartan 6 3.3V (was Re: Virtex6 Virtex4 FPGA compatibility)
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Mon, 09 Mar 2009 08:23:17 +0200
Links: << >>  << T >>  << A >>
rickman wrote:

> of the 3.3 volt standard going away any time soon.  So over the next
> five years, any FPGA aimed at the general logic market will pretty
> much *have* to support 3.3 volts.  As the feature sizes shrink we hear
> that (at least in the case of Xilinx) it becomes prohibitively
> expensive to continue to support higher voltage I/O standards.

The question is what is 3.3v support. For example in CycloneIII the
3.3v IO is almost unusable for any fast signal, the maximum drive
strength is so low. Fortunately if 3.0v is used the drive strength
is better, and 3.0v should be compatible enough with 3.3v standards.

--Kim

Article: 138757
Subject: Re: Regarding to the "change in duty Cycle"
From: goouse@twinmail.de
Date: Mon, 9 Mar 2009 00:00:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Mrz., 05:28, JSreeniv <sreenivas.jyo...@gmail.com> wrote:
> Hi,
> I am presently working on Writing Test cases and Test benches.
> I have a general query which makes me confusion.
> I have a FPGA clock: fpga_clk = 50 MHz and its duty cycle = 50%, here
> is description;
> I am writing a one word data into the register and it will store in
> some address after that it will start transmit using format
> Manchester, and where my output is rcom_tx will get assert high..this
> is the process.
>
> If i changed my duty cycle to 40% and 60% than what can i expect on my
> output does it assert high or low or tri-states.
>
> Please give me some exposure on this confusion, and suggestions.
>
> J.Sreeni,
> Moog India Technology Center(Moog,Inc-USA)

Hi,
the behavior of your circuit depends on how it is written. So, without
any code noone can really say anything useful.
Just one hint:
If your code is well designed and using only the rising edges of your
clock then the clocks duty cycle shouldn't matter at all, at least not
in behavioral simulation.

Have a nice simulation
  Eilert

Article: 138758
Subject: PATA-SATA simulation model
From: "murlary@gmail.com" <murlary@gmail.com>
Date: Mon, 9 Mar 2009 01:03:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
http://www.aipst.com/AIPS7108.pdf
http://www.aipst.com/aips7108.tar.gz

Article: 138759
Subject: Re: Spartan 6 3.3V (was Re: Virtex6 Virtex4 FPGA compatibility)
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 9 Mar 2009 08:44:59 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Kim Enkovaara <kim.enkovaara@iki.fi> wrote:
> rickman wrote:

> > of the 3.3 volt standard going away any time soon.  So over the next
> > five years, any FPGA aimed at the general logic market will pretty
> > much *have* to support 3.3 volts.  As the feature sizes shrink we hear
> > that (at least in the case of Xilinx) it becomes prohibitively
> > expensive to continue to support higher voltage I/O standards.

> The question is what is 3.3v support. For example in CycloneIII the
> 3.3v IO is almost unusable for any fast signal, the maximum drive
> strength is so low. Fortunately if 3.0v is used the drive strength
> is better, and 3.0v should be compatible enough with 3.3v standards.

At the cost of an additional voltage.
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 138760
Subject: Re: Lattice announces ECP3
From: David Brown <david@westcontrol.removethisbit.com>
Date: Mon, 09 Mar 2009 09:54:08 +0100
Links: << >>  << T >>  << A >>
Luc wrote:
> David,
> 
> I know from experience that - at least in Europe - disti's suck. They
> will say of course that the silicon is available. But when it comes to
> production, then you might have a problem.
> 
> Luc
> 

My experience with distributors in Norway has mostly varied between good 
and excellent.  I haven't had to push hard for early samples of FPGAs, 
however, so maybe they are particularly problematic there.



Article: 138761
Subject: FPGA IO Routing
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Mon, 09 Mar 2009 08:23:19 -0500
Links: << >>  << T >>  << A >>
Hi

I have some IO that I am routing from a Virtex 5 to a board connector. I
need to use the IO as either single ended of differential pairs. Would it
be ok to route the signals as though they were single ended even though I
would be using them as differential pairs too. I guess the impedance would
be not 100 ohmns for the differential pairs but would that be ok?

cheers

Jon


Article: 138762
Subject: Image loading into FPGA - from computer
From: Pritha Ghoshal <ghoshal.pritha@gmail.com>
Date: Mon, 9 Mar 2009 06:23:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am working on a project where I need to process an image in the FPGA
and take input image from and send back output image to the computer.

Could someone help regarding how exactly can it be done or a source of
information wither webpage, or books?

 Is it by using parallel port of the Computer, and JTAG port of the
FPGA? Or can the IO ports be used?


Article: 138763
Subject: Timing requirements for generating off-chip clock with DDR register
From: longbrmb@gmail.com
Date: Mon, 9 Mar 2009 07:05:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am building a design that has to interface with some simple chips
outside of my FPGA (I'm using a Virtex II).  These chips are
configured in a daisy-chain and need to receive a serial bitstream
from my design.  I am using a DDR register to generate the clock
signal at the output pin and the data is being clocked out normally.

I had trouble getting the timing to work out right.  I was noticing
that the chip was getting the bitstream off by one bit, i.e. it simply
missed my first data bit and the rest were off by one clock cycle.
Looking at the clock and data outputs on a scope identified the
problem.  Because of the daisy-chain architecture, the data line only
has to drive one chip while the clock is driving all the chips.  The
extra load on the clock caused it to have a longer rise time such that
the transition point for latching the receiving FFs occurred after the
data stream had switched to its next clock cycle.

This basically amounts to a hold time violation since my data did not
remain valid long enough at the receiving end.  A solution I came up
with was to reverse the polarity of the clock at the output.  I
changed the DDR register so that when the internal clock has a rising
edge, the output clock goes low.  It seems to work, but I wanted to
get a second opinion on my solution.

I'm wondering if my original method would have worked in the first
place even if there wasn't a significant load on the clock line?
Since my clock and data are both being generated by FFs at the
outputs, wouldn't the original configuration cause the rising edge of
the clock to occur at the same time as the data was changing thereby
inviting a whole host of metastability problems?

Article: 138764
Subject: Re: Timing requirements for generating off-chip clock with DDR register
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 09 Mar 2009 07:48:00 -0700
Links: << >>  << T >>  << A >>
longbrmb@gmail.com wrote:

> I'm wondering if my original method would have worked in the first
> place even if there wasn't a significant load on the clock line?

It might have worked with the right timing constraints.
STA always reports Fmax for internal registers,
but has no idea about external constraints unless
I tell it.

     -- Mike Treseler

Article: 138765
Subject: Re: Timing requirements for generating off-chip clock with DDR
From: jprovidenza@yahoo.com
Date: Mon, 9 Mar 2009 08:22:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 9, 7:05=A0am, longb...@gmail.com wrote:
> I am building a design that has to interface with some simple chips
> outside of my FPGA (I'm using a Virtex II). =A0These chips are
> configured in a daisy-chain and need to receive a serial bitstream
> from my design. =A0I am using a DDR register to generate the clock
> signal at the output pin and the data is being clocked out normally.
>
> I had trouble getting the timing to work out right. =A0I was noticing
> that the chip was getting the bitstream off by one bit, i.e. it simply
> missed my first data bit and the rest were off by one clock cycle.
> Looking at the clock and data outputs on a scope identified the
> problem. =A0Because of the daisy-chain architecture, the data line only
> has to drive one chip while the clock is driving all the chips. =A0The
> extra load on the clock caused it to have a longer rise time such that
> the transition point for latching the receiving FFs occurred after the
> data stream had switched to its next clock cycle.
>
> This basically amounts to a hold time violation since my data did not
> remain valid long enough at the receiving end. =A0A solution I came up
> with was to reverse the polarity of the clock at the output. =A0I
> changed the DDR register so that when the internal clock has a rising
> edge, the output clock goes low. =A0It seems to work, but I wanted to
> get a second opinion on my solution.
>
> I'm wondering if my original method would have worked in the first
> place even if there wasn't a significant load on the clock line?
> Since my clock and data are both being generated by FFs at the
> outputs, wouldn't the original configuration cause the rising edge of
> the clock to occur at the same time as the data was changing thereby
> inviting a whole host of metastability problems?

Your solution of inverting the clock phase is valid IF you analyze the
setup/hold time
of the receiving devices.  In effect, you put your clock edge right in
the middle of the
data eye and have provided equal setup/hold times.  Is this what the
receivers require?

John Providenza

Article: 138766
Subject: Re: Timing requirements for generating off-chip clock with DDR
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 9 Mar 2009 08:54:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 9, 10:05=A0am, longb...@gmail.com wrote:

> I'm wondering if my original method would have worked in the first
> place even if there wasn't a significant load on the clock line?

Not reliably, a given board might work, another might not.  A
'working' board might stop working, or a 'not working' one might start
working after having been powered up for some period of time.

> Since my clock and data are both being generated by FFs at the
> outputs, wouldn't the original configuration cause the rising edge of
> the clock to occur at the same time as the data was changing thereby
> inviting a whole host of metastability problems?

Yes.

The source of a clock signal must be guaranteed to occur before the
data that you intend to sample with that clock.  By designing both to
come out of the same nominal structure in the same fashion (i.e. two
FFs that are clocked by the same signal) you can't guarantee that
condition will be met.

Kevin Jennings

Article: 138767
Subject: Re: FPGA IO Routing
From: Kolja <ksulimma@googlemail.com>
Date: Mon, 9 Mar 2009 10:00:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
Two single ended lines of Impedance Z can be used as a differential
line of impedance 2*Z
if they are of same length and are seperated enough to not interact
with each others.

As soon as the two lines get closer together the differential
impedance will deviate from 2*Z.
They can still be used both as single ended and differential lines but
will be difficult to terminate
for both cases simultaneously.

Kolja Sulimma

On 9 Mrz., 14:23, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Hi
>
> I have some IO that I am routing from a Virtex 5 to a board connector. I
> need to use the IO as either single ended of differential pairs. Would it
> be ok to route the signals as though they were single ended even though I
> would be using them as differential pairs too. I guess the impedance would
> be not 100 ohmns for the differential pairs but would that be ok?

Article: 138768
Subject: Re: Timing requirements for generating off-chip clock with DDR
From: longbrmb@gmail.com
Date: Mon, 9 Mar 2009 11:00:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 9, 11:54=A0am, KJ <kkjenni...@sbcglobal.net> wrote:

> The source of a clock signal must be guaranteed to occur before the
> data that you intend to sample with that clock. =A0By designing both to
> come out of the same nominal structure in the same fashion (i.e. two
> FFs that are clocked by the same signal) you can't guarantee that
> condition will be met.
>
> Kevin Jennings

So if this implementation would cause problems with the timing, am I
misunderstanding how the "generate clock with DDR register" idea
works?  I was under the impression that using the DDR register would
provide a source synchronous clock that is properly aligned with your
output data stream.  I haven't seen any app notes that talk about this
in detail, they just mention using a DDR register in passing.  Maybe
there are some implied timing constraints when people talk about this
method and I'm just not aware of them?

Matt Longbrake

Article: 138769
Subject: Re: Image loading into FPGA - from computer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Mar 2009 18:39:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
Pritha Ghoshal <ghoshal.pritha@gmail.com> wrote:
 
> I am working on a project where I need to process an image in the FPGA
> and take input image from and send back output image to the computer.

To really answer this question, one would need to know some
details of the alrorithm, but...
 
> Could someone help regarding how exactly can it be done or a source of
> information wither webpage, or books?

I recommend the systolic array architecture for a variety
of FPGA based signal processing algorithms.
 
> Is it by using parallel port of the Computer, and JTAG port of the
> FPGA? Or can the IO ports be used?

In most cases, the parallel port will be too slow.  PCI might
be a good choice.  There are FPGA based PCI boards available.
Do you have to build the hardware or just the HDL code?

-- glen 

Article: 138770
Subject: Re: FPGA IO Routing
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Mon, 09 Mar 2009 14:20:46 -0500
Links: << >>  << T >>  << A >>
Ok thanks for the info.


>Two single ended lines of Impedance Z can be used as a differential
>line of impedance 2*Z
>if they are of same length and are seperated enough to not interact
>with each others.
>
>As soon as the two lines get closer together the differential
>impedance will deviate from 2*Z.
>They can still be used both as single ended and differential lines but
>will be difficult to terminate
>for both cases simultaneously.
>
>Kolja Sulimma
>
>On 9 Mrz., 14:23, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>> Hi
>>
>> I have some IO that I am routing from a Virtex 5 to a board connector.
I
>> need to use the IO as either single ended of differential pairs. Would
it
>> be ok to route the signals as though they were single ended even though
I
>> would be using them as differential pairs too. I guess the impedance
would
>> be not 100 ohmns for the differential pairs but would that be ok?
>



Article: 138771
Subject: Re: Image loading into FPGA - from computer
From: Pritha Ghoshal <ghoshal.pritha@gmail.com>
Date: Mon, 9 Mar 2009 12:42:20 -0700 (PDT)
Links: << >>  << T >>  << A >>

Thanks a lot for your reply.

The algorithm will be simple - edge detection and colour conversion or
something similar.

And I need to mainly do the HDL code. Is some extra hardware crucial,
or is it possible to work only with the computer and FPGA kit?

Pritha


Article: 138772
Subject: Re: Want to buy: FPGA T-Shirt $$
From: rickman <gnuarm@gmail.com>
Date: Mon, 9 Mar 2009 12:48:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 5, 2:42=A0pm, justforpret...@gmail.com wrote:
> I hope this isn't terribly inappropriate to post here. =A0I want to buy
> three FPGA-related T-shirts. =A0I know that Altera and Xilinx have in
> the past given out freebie shirts, and I'm trying to track some down
> as gifts for my roommates, who work with FPGAs. =A0I will pay good money
> for them!!
>
> Let me know if you have something lying around that you don't mind
> parting with. =A0They primarily use Altera, so that's preferable.


This will be a good test to see if the vendors still monitor this
group.  I can't imagine that a vendor would not want to reward such
loyal customers.

I hope that's not laying it on too thick...  ;^)

Rick

Article: 138773
Subject: Re: Image loading into FPGA - from computer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 9 Mar 2009 19:50:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
Pritha Ghoshal <ghoshal.pritha@gmail.com> wrote:
 
> The algorithm will be simple - edge detection and colour 
> conversion or something similar.
 
> And I need to mainly do the HDL code. Is some extra hardware crucial,
> or is it possible to work only with the computer and FPGA kit?

For the problems I am used to, speed is very important. 
If you just need to demonstrate a working algorithm, a parallel
port might be fine.  

The systolic array architecture (see Systolic_array in wikipedia)
is very different from the usual software implementation.  

To demonstrate that you understand the algorithm, speed isn't
important, though it is usually the reason behind hardware
implementations.

-- glen

Article: 138774
Subject: Re: Image loading into FPGA - from computer
From: jaxato@gmail.com
Date: Mon, 9 Mar 2009 13:30:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I worked on a video processing project not so long ago, and I
think I might help here.
Our project was an image binarization system based on euler numbers.
The design
did not have any minimum clock frequency and did the processing on-the-
fly requiring
only a clock input and an 8-bit pixel data bus (grayscale).

We actually implemented two versions of the test unit.
1) We used an 8bit embedded controller programmed in C with a port of
a filesystem,
to which an SD memory card containing some test binary files was
connected.
These files were originally generated by matlab. The 8bit embedded
controller then
read the files sequentially and streamed it to our unit under test
(UUT).
We achieved a data rate of about 300KBytes with this method. For every
frame that was
streamed to the UUT, we obtained an 8bit threshold value which was
then written back
to the SD memory card as a new result file.

2) In the second method, we used a usb device by microchip with the
CDC stack. The
device that we used was the pic18f2450. We modified the CDC stack
which is a free
usb to serial converter offered by microchip, to allow us to write
parallel data to the
controller's port instead of it being serial. We actually kept the
serial output line, so the
controller was just writing to the UUT in parallel and reading the
result, which was an 8bit
threshold value, and serially sending it back to the host PC.
The nice thing about the second implementation was that it is totally
transparent in matlab.
With the use of the open read write files commands, you can actually
use the serial port
to stream data to a peripheral. Our data rate was less that the first
implementation
at around 150KByte. There was room for improvement with this
implementation as the
microcontroller we were using had only 760Byte of data ram. But it
made our life simpler with
the testing.

This is more or less the approach that we used to test a video
processing system in HW.
I wanted to say also that you should first try to simulate your
solution as it will save you a lot
of time. We used the read and write command as available in VHDL to
initially generate intermediate
results that we would eventually compare to our "golden" values,
values obtained from matlab and
known to be good.

Jacques

On Mar 9, 3:50=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Pritha Ghoshal <ghoshal.pri...@gmail.com> wrote:
> > The algorithm will be simple - edge detection and colour
> > conversion or something similar.
> > And I need to mainly do the HDL code. Is some extra hardware crucial,
> > or is it possible to work only with the computer and FPGA kit?
>
> For the problems I am used to, speed is very important.
> If you just need to demonstrate a working algorithm, a parallel
> port might be fine. =A0
>
> The systolic array architecture (see Systolic_array in wikipedia)
> is very different from the usual software implementation. =A0
>
> To demonstrate that you understand the algorithm, speed isn't
> important, though it is usually the reason behind hardware
> implementations.
>
> -- glen




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