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 149725

Article: 149725
Subject: Re: Debugging with a single LED
From: Newman <newman5382@yahoo.com>
Date: Sat, 20 Nov 2010 18:12:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 20, 7:22=A0pm, Allan Herriman <allanherri...@hotmail.com> wrote:
> On Sat, 20 Nov 2010 23:22:48 +0000, Philip Pemberton wrote:
> > Here's a good mind bender for the gurus...
>
> > Problems:
> [snip]
> > =A0 2) The only real output the FPGA has is an LED
>
> When I worked at Fujitsu, we had a controller board with a GPIO driven
> status LED on its front panel. =A0When it was in debug mode (e.g. after a
> crash), software on the target system would implement a bit-bashed UART
> and send the resulting bits to the LED. =A0We had a little gizmo with a
> phototransistor and an line-powered RS232 buffer that would send the bits
> back to a serial port on a PC so the debug results (in this case a stack
> trace) could be seen on a terminal emulator program. =A0A magnet in the
> gizmo held it on to the panel in the right place above the LED.
>
> You shouldn't have any trouble rolling your own UART to do something
> similar. =A0If it's a Xilinx part, I recommend a picoblaze + picoblaze ua=
rt
> combination if there's more than a trivial amount of information to send.
>
> Cheers,
> Allan

If it is a Xilinx FPGA, you may also consider using the JTAG UART IP
block where you can get terminal information via the jtag connector.
You may also consider sending a walking 1 and walking 0 across the
interface to the FPGA and observing the signal with chipscope if you
have it.

Article: 149726
Subject: Re: Huffman encoder/Decoder For Text data compression
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 21 Nov 2010 02:59:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
kude <tadmas09@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> Huffman encoder/Decoder For Text data compression
 
>  I am working on Huffman Encoder/Decoder for text    
>  compression/Decompression.And here are the things not clear for me.
> 1.How can I give text input (Whole text once) to the FPGA.

Usually clocked in a byte at a time, but for speed could be
multiple bytes in parallel at a time.

> 2.When I encode the data the output code length is not fixed 
> and how can I  manage this with constant I/O pins of the FPGA.

Again, clocked out one byte or some other number of bits, at
a time.  Probably an enable output and a done (EOF) output.

> 3.When Encoding the text I have to use heaps,Sort and mearge 
> but this things are not synthesizable in FPGA

There are ways to do sorts.  Well, there are a few different
ways to do Huffman.  One is with a static table based on the
usual probabilities.  That is what Group 3 fax uses.  I believe
another is to adapt as you go along, maybe recomputing every
so often, and having the decoder do the same.  Otherwise, you
have to go through the whole file, compute the table, then
go through again.

-- glen

Article: 149727
Subject: Re: test peripheral example in xilinx XPS
From: "bhatti" <bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com>
Date: Sat, 20 Nov 2010 22:34:04 -0600
Links: << >>  << T >>  << A >>

>
>You can load the code into DDR sdram using XMD.
>If you have a compact flash system, an ACE file can load DDR SDRAM for
>you.
>If you have non-volatile memory, a boot loader program in BRAM can
>move the executable from nvmem to DDR.
>
>You should read the tutorials and manuals.
>
If there is a tutorial (with example) covering this typical issue, please
let me know 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149728
Subject: Re: Multiple Reset Inputs
From: Allan Herriman <allanherriman@hotmail.com>
Date: 21 Nov 2010 09:41:45 GMT
Links: << >>  << T >>  << A >>
On Sat, 20 Nov 2010 18:11:55 -0800, KJ wrote:

> On Nov 20, 7:09 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
>> On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:
>> > [snip]
>> > Lastly, what is wrong with some combinatorial logic in the
>> > asynchronous path? Since the inputs arrive at who knows what time the
>> > added delay of the combinatorial logic only adds a small amount to
>> > that best guess time! Now I suppose there could be special cases of
>> > the input signals being very narrow pulses where the delay may be an
>> > impact but then they are going to have problems being detected by the
>> > synchronizer - but you did not mention that detail.
>>
>> The OP is worried about glitches in the combinatorial logic.  In
>> general, a glitch can be generated at the output of some combinatorial
>> logic whenever any input changes, even if (under steady state
>> conditions) that input should not affect the output.
>>
>>
> Actually, the OP is worried about something that does not need to be
> worried about.  Glitches causing resets are things that need to be
> avoided when you're trying to *prevent* a false reset from occurring
> (i.e. resetting when you don't want to be).  What the OP describes is
> two inputs which are supposed to cause a reset.  A 'glitch' on one of
> them would be a case of something that should cause a reset, not
> something that should be prevented.

Exactly right, which is why I said:

"For the specific case of an AND ... the OP needn't worry."

Cheers,
Allan

Article: 149729
Subject: Re: Spartan3 device with long availability
From: Thomas Heller <theller@ctypes.org>
Date: Sun, 21 Nov 2010 11:14:18 +0100
Links: << >>  << T >>  << A >>
Am 20.11.2010 13:03, schrieb Kolja Sulimma:
>>   I try to avoid BGA.
>
> Don't.
> It has many advantages over the other packages,
> among them
> - better yield in soldering.
> - less EMI
> - less ground bounce
> - less board space
> - better cooling
>
> Kolja

How are you doing prototyping with BGA packages?

Thomas

Article: 149730
Subject: Re: Spartan3 device with long availability
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 21 Nov 2010 04:27:56 -0800 (PST)
Links: << >>  << T >>  << A >>
Thomas

I would expect the XC3S200 and XC3S400 to have a long life even though
it is 6-7 years or so since there were first available. I won't be
surprised if these are still available in 10 years time. What is
likely is that they will get more expensive, and maybe have longer
lead times, in the coming years as Spartan-6, and later, take over as
main low cost families.

II would also consider Spartan-6 as it will have an even longer
lifetime. Most of Spartan-6 is available now in small numbers if not
large numbers. Digikey are showing stock in the TQFP package.

John Adair
Enterpoint Ltd. - Home of Drigmorn3. The Cost Effective Spartan-6
Development Board.


On Nov 20, 9:27=A0am, Thomas Heller <thel...@ctypes.org> wrote:
> I have to develop some electronics that will probably fit nicely into
> a spartan3 device xc3s200 or xc3s400. =A0Which series / package should
> I choose for long availability?
>
> I am considering the TQFP144 or PQ208 package, I try to avoid BGA.
> Will there be any differences in the long-term availability
> between spartan 3, spartan 3A, spartan 3E, or even spartan 3AN?
>
> Thanks,
> Thomas


Article: 149731
Subject: Network stack on Xilinx, Alterra ?
From: Daku <dakupoto@gmail.com>
Date: Sun, 21 Nov 2010 06:42:37 -0800 (PST)
Links: << >>  << T >>  << A >>
Could some FPGA guru please help me ? I was wondering if any of the
currently available FPGA families - Alterra, Xilinx etc., have any
built-in network stack (seven layer ISO/OSI model). Any information
regarding this would be greatly appreciated. Thanks in advance for
your help.

Article: 149732
Subject: Re: test peripheral example in xilinx XPS
From: Newman <newman5382@yahoo.com>
Date: Sun, 21 Nov 2010 07:41:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 20, 11:34=A0pm, "bhatti"
<bhatti.uzair@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com> wrote:
> >You can load the code into DDR sdram using XMD.
> >If you have a compact flash system, an ACE file can load DDR SDRAM for
> >you.
> >If you have non-volatile memory, a boot loader program in BRAM can
> >move the executable from nvmem to DDR.
>
> >You should read the tutorials and manuals.
>
> If there is a tutorial (with example) covering this typical issue, please
> let me know =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

Have a look at this.
http://www.xilinx.com/support/documentation/boards_and_kits/ug494.pdf

I searched and found this document just to see how difficult it was to
find.
I found it in 5 minutes.

Article: 149733
Subject: Re: Network stack on Xilinx, Alterra ?
From: Mike Treseler <mtreseler@gmail.com>
Date: Sun, 21 Nov 2010 09:42:35 -0800
Links: << >>  << T >>  << A >>
On 11/21/2010 6:42 AM, Daku wrote:
> Could some FPGA guru please help me ? I was wondering if any of the
> currently available FPGA families - Alterra, Xilinx etc., have any
> built-in network stack (seven layer ISO/OSI model). Any information
> regarding this would be greatly appreciated. Thanks in advance for
> your help.

A network stack is mostly software.
An fpga might help out on layer 1 or 2 with
line encoding/decoding or packing/picking
bytes from a bitstream.

        -- Mike Treseler

Article: 149734
Subject: Re: Spartan3 device with long availability
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sun, 21 Nov 2010 21:12:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
John Adair <g1@enterpoint.co.uk> wrote:
..
> large numbers. Digikey are showing stock in the TQFP package.

... with a constant lead time 6 weeks in the future.

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

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

Article: 149735
Subject: Re: [O.T.] Audio DAC as AWG (test source)?
From: Fred Marshall <fmarshall_xremove_the_xs@xacm.org>
Date: Sun, 21 Nov 2010 13:34:20 -0800
Links: << >>  << T >>  << A >>
On 10/31/2010 7:06 AM, Pete Fraser wrote:
> I'm just finishing up design of an analog data acquisition system
> (16 bits, 100 kHz sampling), and need to come up with a
> test / verification scheme. I've looked at some of the arbitrary
> waveform generators available, and they seem to be expensive,
> and not very accurate (13 or 14 bits).
>
> There seems to be a wide variety of inexpensive USB and
> firewire audio DACs available, and some of them are
> specified to 192 kHz sampling and 24 bits. If I could buy
> a DAC with 24 bits and 192 kHz (or higher) sampling I
> could write some code to generate a source file, play it through
> the DAC, capture the resultant signals in the test system, and
> analyze the system performance.
>
> Has anyone here done that? Can you offer any pointers?
> It's not clear from the specifications / manual of the DACs I've
> looked at whether filtering can be disabled. Most are
> specified from 20 Hz to 20 kHz, and seem intended to
> take in 44.1 kHz or 48 kHz, do a filtered up-conversion,
> and (presumably) have a sloppy output filter. Some specify
> that they can accept 192 kHz, but I've no idea what filters
> they use and whether they can be bypassed.
>
> Any thoughts / observations?
>
> Thanks
>
> Pete
>
>

Pete,

I've not done this but it seems to me that a high-quality sine generator 
would be very useful and maybe easier to come by than an arbitrary 
signal generator.
I'd be thinking sine waves and step inputs.

You could force the FT length to match an integral number of periods 
after having gathered a bunch of sinusoid samples.  If the generator 
clock is locked to the sample clock or vice-versa so much the better.
Then you could look for distortion and noise levels (which one might 
hope would be close to the predicted quantization noise.

Step inputs would give you a good idea of overall transient performance: 
slew rate, rise time, ringing, recovery times, etc.

I didn't see any strange input requirements here:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.8077&rep=rep1&type=pdf

But there are a bunch of good ideas there at least.

Fred

Article: 149736
Subject: Re: Spartan3 device with long availability
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 21 Nov 2010 23:07:13 GMT
Links: << >>  << T >>  << A >>
Thomas Heller <theller@ctypes.org> wrote:

>Am 20.11.2010 13:03, schrieb Kolja Sulimma:
>>>   I try to avoid BGA.
>>
>> Don't.
>> It has many advantages over the other packages,
>> among them
>> - better yield in soldering.
>> - less EMI
>> - less ground bounce
>> - less board space
>> - better cooling
>>
>> Kolja
>
>How are you doing prototyping with BGA packages?

Get your own reflow oven kit like this:

http://www2.conrad.nl/goto.php?artikel=530330

I'm pretty sure similar (much cheaper) kits are offered on Ebay. I
never tried it but it looks usefull for prototyping.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 149737
Subject: Re: Network stack on Xilinx, Alterra ?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 22 Nov 2010 00:25:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mike Treseler <mtreseler@gmail.com> wrote:
> On 11/21/2010 6:42 AM, Daku wrote:
>> Could some FPGA guru please help me ? I was wondering if any of the
>> currently available FPGA families - Alterra, Xilinx etc., have any
>> built-in network stack (seven layer ISO/OSI model). Any information
>> regarding this would be greatly appreciated. Thanks in advance for
>> your help.
 
> A network stack is mostly software.
> An fpga might help out on layer 1 or 2 with
> line encoding/decoding or packing/picking
> bytes from a bitstream.

There are processors like nios and microblaze designed to
work with certain FPGA families, and I believe that there are
TCP/IP versions for them.  Well, full stack is a little much,
as some of those layers are part of the application program,
but at least to layer three.

I believe it isn't so hard to do UDP with a simple state machine
in an FPGA, but TCP would generally need a programmable processor.

Also possible is an external processor doing the IP stack and
buffering, then handing the data off to the FPGA.

-- glen

Article: 149738
Subject: Re: Multiple Reset Inputs
From: Analog_Guy <analog_guy@hotmail.com>
Date: Sun, 21 Nov 2010 17:40:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 21, 4:41=A0am, Allan Herriman <allanherri...@hotmail.com> wrote:
> On Sat, 20 Nov 2010 18:11:55 -0800, KJ wrote:
> > On Nov 20, 7:09=A0pm, Allan Herriman <allanherri...@hotmail.com> wrote:
> >> On Sat, 20 Nov 2010 06:55:28 -0800, Michael Karas wrote:
> >> > [snip]
> >> > Lastly, what is wrong with some combinatorial logic in the
> >> > asynchronous path? Since the inputs arrive at who knows what time th=
e
> >> > added delay of the combinatorial logic only adds a small amount to
> >> > that best guess time! Now I suppose there could be special cases of
> >> > the input signals being very narrow pulses where the delay may be an
> >> > impact but then they are going to have problems being detected by th=
e
> >> > synchronizer - but you did not mention that detail.
>
> >> The OP is worried about glitches in the combinatorial logic. =A0In
> >> general, a glitch can be generated at the output of some combinatorial
> >> logic whenever any input changes, even if (under steady state
> >> conditions) that input should not affect the output.
>
> > Actually, the OP is worried about something that does not need to be
> > worried about. =A0Glitches causing resets are things that need to be
> > avoided when you're trying to *prevent* a false reset from occurring
> > (i.e. resetting when you don't want to be). =A0What the OP describes is
> > two inputs which are supposed to cause a reset. =A0A 'glitch' on one of
> > them would be a case of something that should cause a reset, not
> > something that should be prevented.
>
> Exactly right, which is why I said:
>
> "For the specific case of an AND ... the OP needn't worry."
>
> Cheers,
> Allan

Thanks for all of your feedback.  The only reason I mentioned the AND
function
is because I generally use active LO resets.  I can see now that
having some
logic in the asynchronous reset path is not a big deal since I am
actually dealing
with a reset circuit.

I just thought I had heard somewhere that avoiding combinational logic
in the
asynchronous reset path was a good design practice.

Article: 149739
Subject: Re: Multiple Reset Inputs
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 21 Nov 2010 19:02:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 21, 8:40=A0pm, Analog_Guy <analog_...@hotmail.com> wrote:

>
> I just thought I had heard somewhere that avoiding combinational logic
> in the
> asynchronous reset path was a good design practice.- Hide quoted text -
>

In certain situations combinatorial logic in the reset path should be
avoided.  See my reply to your post in comp.lang.vhdl

KJ

Article: 149740
Subject: Procedures and Registers
From: makeuptest <spamgoeshere2@yahoo.com>
Date: Sun, 21 Nov 2010 19:34:19 -0800 (PST)
Links: << >>  << T >>  << A >>
I was writing some code and decided to make it a procedure to put in a
library.  I have written functions many times, but not a procedure.
This was a routine for some registers and counters internal to the
procedure and so required a clock and reset.  I couldn't figure out
how to wirte it so that it would be inside a clocked process, so I
added the clock and reset to the inputs and put the clocking code
within the procedure.

That was all well and good.  But when I tried to test it, none of the
internal variables that should have created registers were being
remembered.  I ran a simulation and the variables were getting reset
initially, but on the next entry to the procedure they were back to
being undefined.

Do I have a basic misunderstanding about how procedures operate?  I
haven't found a good reference to explain enough to figure out what I
am doing wrong.

Greg

Article: 149741
Subject: Re: Procedures and Registers
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 21 Nov 2010 21:00:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 21, 10:34=A0pm, makeuptest <spamgoeshe...@yahoo.com> wrote:

>
> That was all well and good. =A0But when I tried to test it, none of the
> internal variables that should have created registers were being
> remembered. =A0I ran a simulation and the variables were getting reset
> initially, but on the next entry to the procedure they were back to
> being undefined.
>

Procedures do not inherently 'remember' the values of internal
variables or signals as you would have in a process.  Instead you must
make the signal available on the interface of the procedure and hook
up a real signal to that port.

This generally means that you must actually add two signals to the
interface of the procedure:  one is an 'input' to the procedure which
represents the current state of the signal; the other is an 'output'
of the procedure which represent the next state of the signal.

> Do I have a basic misunderstanding about how procedures operate?

Yes...you can't hide signals within a procedure.

Kevin Jennings

Article: 149742
Subject: Re: Debugging with a single LED
From: saar drimer <saardrimer@gmail.com>
Date: Mon, 22 Nov 2010 08:07:28 -0800 (PST)
Links: << >>  << T >>  << A >>
> Can anyone think of an easier way to do this?

Are the JTAG pins available?

If so, Chipscope with VirtualIO should be the easiest for this kind of
debug. You can desolder the PIC and manually loopback/short the pads
and then change the stimulus through the chipscope GUI and see if the
signals propagate. With one design you can then test all routes. If
this is an Altera device, use SignalTap.

saar.

Article: 149743
Subject: Re: Spartan3 device with long availability
From: John Adair <g1@enterpoint.co.uk>
Date: Mon, 22 Nov 2010 08:35:19 -0800 (PST)
Links: << >>  << T >>  << A >>
Uwe

Spartan-6 availability is improving very rapidly and in many cases is
now on shorter lead time than Spartan-3 parts. We have a considerable
amount here now of the parts we use most awaiting some time on our
line to build more development boards. 4-6 weeks is usually the
standard lead time value, usually quoted in better times, on Spartan
families if you buy them in any numbers.

The general components shortage is only starting to improve and Xilinx
are doing a much better job than most vendors. It's not quite a
paradise yet but I expect Q1/2011 we will be back to nearly normal
supply conditions and almost certainly for FPGA availability.

John Adair
Enterpoint Ltd.

On Nov 21, 9:12=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> John Adair <g...@enterpoint.co.uk> wrote:
>
> ..
>
> > large numbers. Digikey are showing stock in the TQFP package.
>
> ... with a constant lead time 6 weeks in the future.
>
> --
> Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar=
mstadt.de
>
> Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 149744
Subject: FPGA-based implementation of Camera Link standard
From: "Shervin" <Shervin.Mehryar@n_o_s_p_a_m.mdacorporation.com>
Date: Mon, 22 Nov 2010 10:56:02 -0600
Links: << >>  << T >>  << A >>
Greetings, I have an FPGA board that has JPEG 2000 images stored in its
memory and need to send the images to another device that has a Cemara Link
standard-based interface. The Camera Link docuement explains the overall
communication protocol: for example for a basic interface there are 3 8-bit
pixel-data lines and 3 main control signals FVAL, DVAL, and LVAL. In my
case, the images that I have are in the following format: meta data + byes
of image data. In the case of basic interface, do I just load the image
data 3 bytes at a time, put them in parallel on the pixel-data lines while
the FVAL, DVAL, LVAL signals are raised until the end of image bytes? Is
this the basic idea?  

Thank you in advance for your time, look forward to your kind reponse. 

-Shervin


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149745
Subject: Re: FPGA-based implementation of Camera Link standard
From: Gabor <gabor@alacron.com>
Date: Mon, 22 Nov 2010 10:44:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 22, 11:56=A0am, "Shervin"
<Shervin.Mehryar@n_o_s_p_a_m.mdacorporation.com> wrote:
> Greetings, I have an FPGA board that has JPEG 2000 images stored in its
> memory and need to send the images to another device that has a Cemara Li=
nk
> standard-based interface. The Camera Link docuement explains the overall
> communication protocol: for example for a basic interface there are 3 8-b=
it
> pixel-data lines and 3 main control signals FVAL, DVAL, and LVAL. In my
> case, the images that I have are in the following format: meta data + bye=
s
> of image data. In the case of basic interface, do I just load the image
> data 3 bytes at a time, put them in parallel on the pixel-data lines whil=
e
> the FVAL, DVAL, LVAL signals are raised until the end of image bytes? Is
> this the basic idea? =A0
>
> Thank you in advance for your time, look forward to your kind reponse.
>
> -Shervin
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

It would be best to find out from the company that makes your
framegrabber
if they need any special formatting.  Many times you need to keep a
constant
line size and frame size, which is not really appropriate for JPEG
images,
since their size depends on the complexity of the image.  Some
framegrabbers
will drop any data that is sent beyond the length of the defined line
or
image width.  Also if you are using the "base" Camera Link hardware
and
want to use three bytes, be aware that most framegrabbers only allow
this
for RGB mode, so the three bytes are regarded as one "pixel".

If you are making the logic for both ends of the interface you can
obviously do
anything you want.  We have made cameras and framegrabbers that can
handle JPEG compressed images using a straightforward frame interface
that does not require LVAL to toggle.  It's been a while since we did
this,
but as I recall we used a 2-tap mode (16 bits per clock) and used the
DVAL signal to indicate valid data because the rate data came from the
JPEG compression core was not constant.

Camera Link does not have any provisions for variable length frames,
so there's no standard way to do this.

HTH,
Gabor

Article: 149746
Subject: minimum clock period of a combinational circuit
From: "dila77" <dila77@n_o_s_p_a_m.live.com>
Date: Mon, 22 Nov 2010 13:19:30 -0600
Links: << >>  << T >>  << A >>
Hi,
please, how can I find out the minimum clock period (the maximum clock
frequency in MHz) of a combinational circuit (for example, for a full
adder) ?
After the synthesizing and implementation I got the following message:

Clock Information:
------------------
No clock signals found in this design
Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design
Timing Summary:
---------------
Speed Grade: -4
   Minimum period: No path found
   Minimum input arrival time before clock: No path found
   Maximum output required time after clock: No path found
   Maximum combinational path delay: 9.033ns

Is there any way to know the minimum clock period ?

Thanks :)

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149747
Subject: Re: minimum clock period of a combinational circuit
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 22 Nov 2010 13:51:07 -0600
Links: << >>  << T >>  << A >>
>Hi,
>please, how can I find out the minimum clock period (the maximum clock
>frequency in MHz) of a combinational circuit (for example, for a full
>adder) ?
>After the synthesizing and implementation I got the following message:
>
>Clock Information:
>------------------
>No clock signals found in this design
>Asynchronous Control Signals Information:
>----------------------------------------
>No asynchronous control signals found in this design
>Timing Summary:
>---------------
>Speed Grade: -4
>   Minimum period: No path found
>   Minimum input arrival time before clock: No path found
>   Maximum output required time after clock: No path found
>   Maximum combinational path delay: 9.033ns
>
>Is there any way to know the minimum clock period ?
>
>Thanks :)

Is your adder driven by data that is clocked? Looking at the report it
seems that there are no clocked devices in your design. The minimum period
will be derived using the worst case delay between clocked primitives. If
you dont have any it cant calculate it. 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149748
Subject: Re: FPGA-based implementation of Camera Link standard
From: "Shervin" <Shervin.Mehryar@n_o_s_p_a_m.n_o_s_p_a_m.mdacorporation.com>
Date: Mon, 22 Nov 2010 15:21:01 -0600
Links: << >>  << T >>  << A >>
Thank you Gabor for your useful tips. I will try to bug the company for
some more information and see if I can do anything about it.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 149749
Subject: Synthesis/place and route with Solid-State Drives
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Mon, 22 Nov 2010 13:28:19 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi everyone

I've heard from a friend of a friend that running synthesis and
implementation with a solid-state drive can yield substantial speed
gains compared with the same process run on a machine with a regular
hard drive. Are there any FPGA designers here that have tried it? If
so, is there any truth to that statement and can you tell how much
performance has been gained?

Best regards






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