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
2017JanFebMarApr2017

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 104950

Article: 104950
Subject: Re: LUT4 INIT value to implement 2:1 MUX ?
From: "Peter Alfke" <peter@xilinx.com>
Date: 10 Jul 2006 13:18:52 -0700
Links: << >>  << T >>  << A >>
There are 4! = 24 different ways to route three signals to 4 pins.
Peter Alfke
=============
Tommy Thorn wrote:
> John_H wrote:
> >    parameter I0 = 16'haaaa,
> >              I1 = 16'hcccc,
> >              I2 = 16'hf0f0,
> >              I3 = 16'hff00;
> >
> > LUT4 #( .INIT( I2 & I1 | ~I2 & I0 ) )
> >    MyMux ( .I0(input1), I1(input2), I2(select), I3(1'b0) );
>
> Very elegant!
>
> One question though, doesn't explicitly instantiating the LUT4 like
> this constrain the routing or is it smart enough to know that it can
> freely permute the pins with a suitable permutation of the
> initialization vector?
>
> Also, this trick should generalize nicely to a Xilinx LUT6, but what
> about the Stratix II ALMs?
> 
> Tommy


Article: 104951
Subject: Re: LUT4 INIT value to implement 2:1 MUX ?
From: John_H <johnhandwork@mail.com>
Date: Mon, 10 Jul 2006 20:19:14 GMT
Links: << >>  << T >>  << A >>
Tommy Thorn wrote:
> John_H wrote:
>>    parameter I0 = 16'haaaa,
>>              I1 = 16'hcccc,
>>              I2 = 16'hf0f0,
>>              I3 = 16'hff00;
>>
>> LUT4 #( .INIT( I2 & I1 | ~I2 & I0 ) )
>>    MyMux ( .I0(input1), I1(input2), I2(select), I3(1'b0) );
> 
> Very elegant!
> 
> One question though, doesn't explicitly instantiating the LUT4 like
> this constrain the routing or is it smart enough to know that it can
> freely permute the pins with a suitable permutation of the
> initialization vector?
> 
> Also, this trick should generalize nicely to a Xilinx LUT6, but what
> about the Stratix II ALMs?
> 
> Tommy

The routing to the individual pins is free to move unless otherwise 
constrained.  The LOCK_PINS constraint can be used to fix individual 
pins with a format like "INST MyMux LOCK_PINS=I1:A4;" to geep the .I1 
signal on F4 or G4 or all four pins can be locked with the "... 
LOCK_PINS=ALL;" which I needed recently to keep the tools from 
optimizing a LUT used to select between two routing delays.

I haven't tried to instantiate an Altera ALM so I don't know if they 
have a similar INIT parameter.  Your mileage may vary.

Article: 104952
Subject: Re: The FFs with synchronous reset perform worse?
From: mk <kal*@dspia.*comdelete>
Date: Mon, 10 Jul 2006 21:08:28 GMT
Links: << >>  << T >>  << A >>
On 9 Jul 2006 22:45:20 -0700, "Stanley Lee" <lizhongqi@hotmail.com>
wrote:

>
>mk ???
>
>> On 9 Jul 2006 20:35:03 -0700, "Stanley Lee" <lizhongqi@hotmail.com>
>> wrote:
>>
>> >Hi, all:
>> >The FFs can be reset synchronously or asynchronously. And in ASIC
>> >design, the FFs with asynchronous reset will be "smaller".
>>
>> I am not sure why you put it into quotes but this statement is almost
>> definitely false. I've never seen an ASIC library where the async
>> reset flops were not larger in area than non-reset flops from which
>> one usually makes the sync flops. Non-reset flops are also usually
>> faster and the resulting design is faster again because one usually
>> has a path in the logic which resets the flop so the sync reset gets
>> merged with that path.
>
>Thank you for your answer, and what you say is about ASIC or FPGA? I
>want to know the performance of the two kind of FFs in FPGA.

This is for ASIC. For FPGAs all the cells are already hard-wired. I
haven't looked carefully but I doubt the timing of the DFFs in any
FPGA depends on whether it's configured for async/sync or no reset. In
a way you can assume that the async input is still there but it's tied
to in-active always and that doesn't change the timing of the cell. In
an ASIC, you use a different cell.

Article: 104953
Subject: High-speed DAC/ADC with FPGA
From: "rnbrady" <rnbrady@gmail.com>
Date: 10 Jul 2006 14:56:57 -0700
Links: << >>  << T >>  << A >>
Hi folks

I'm working with an Altera Stratix ep1s10 on a development board. The
data sheet says the IO can operate at rates up to 800 MSPS. If I have a
look on the internet, I see DAC and ADC technology going up to 400
MSPS.

My application is software defined radio, where the general mantra is
to do as little analog front-end as possible, i.e. sample as fast as
you can.

What are the limits on my conversion rates? I doubt it's even remotely
possible for me to do data conversion at 400 MSPS? My main concern is
the PCB layout, with about 15cm of track and a header between the FPGA
and the conversion chips. Crosstalk, EMI and impedance matching are all
things I know very little about.

Is there a more appropraiate group to post on?

Thanks in advance,
Richard


Article: 104954
Subject: Re: High-speed DAC/ADC with FPGA
From: "PeterSmith1954@googlemail.com" <PeterSmith1954@googlemail.com>
Date: 10 Jul 2006 15:18:42 -0700
Links: << >>  << T >>  << A >>
rnbrady wrote:
> Hi folks
>
> I'm working with an Altera Stratix ep1s10 on a development board. The
> data sheet says the IO can operate at rates up to 800 MSPS. If I have a
> look on the internet, I see DAC and ADC technology going up to 400
> MSPS.
>
> My application is software defined radio, where the general mantra is
> to do as little analog front-end as possible, i.e. sample as fast as
> you can.
>
> What are the limits on my conversion rates? I doubt it's even remotely
> possible for me to do data conversion at 400 MSPS? My main concern is
> the PCB layout, with about 15cm of track and a header between the FPGA
> and the conversion chips. Crosstalk, EMI and impedance matching are all
> things I know very little about.
>
> Is there a more appropraiate group to post on?
>
> Thanks in advance,
> Richard

Crossposted to s.e.d.
There's no reason you can't sample at 400MS/s with the right parts and
proper layout. At those speeds you do have to be very careful about
layout, and differential sampling is probably a *very* good idea.

More details are really needed:


What type of header are you talking about? I have run signals at 5Gb/s
through connectors designed for the task with little loss and very low
crosstalk, but they aren't cheap. Is this an existing header?

Does this mean you want to run wires, or are you making a circuit board
for the A-D? You are unlikely to get high data rates with handwired
circuitry (you can get reasonably high speeds, but not too high unless
you are an expert in wirewrap and routing ;).

You say you are using a development board. What documentation is there
for it? Point us at some details if you have them.

What is the interface from your A-D converter(s)? Serial? Parallel?
Parallel may take more lines, but it also gives the lowest data rate.
There are also tricks of synchronised sampling (using multiple
converters, suitably calibrated) to increase the effective sample rate,
should that be necessary. On that subject, is there a particular A-D
device you have in mind, or are you open to suggestions?

What signal frequency range are you particularly interested in getting?
If you are not sure of what to use, this will let others help you
choose an appropriate device.

Even if you sample with a decent A-D, you should still (in my opinion)
put an anti-aliasing filter on the front end, and buffering to prevent
loading. (Some parts have them internally). Unless you have a buffered
output from something, you are probably going to have to put down at
least some analog circuitry apart from the A-D(s).

Speaking of that, what RF device did you intend to use to get the
signal in the first place?

Answer those (reply to both groups) and some of the denizens of s.e.d.
will no doubt dispense some ideas, and no doubt ask more questions.

Cheers

PeteS


Article: 104955
Subject: Re: High-speed DAC/ADC with FPGA
From: "Peter Alfke" <peter@xilinx.com>
Date: 10 Jul 2006 15:33:47 -0700
Links: << >>  << T >>  << A >>
Many A/D converters have a double-width digital interface, which
reduces the FPGA capture rate by a factor two (but doubles the number
of bits)
I have seen sample rates of 1 Gsps interfaced to FPGAs (guess which
ones).
Make sure that the sampling clock is as clean as possible. Any jitter
will severely impact your analog noise floor, i.e. will reduce the
dynamic range.

Peter Alfke, Xilinx
====================
rnbrady wrote:
> Hi folks
>
> I'm working with an Altera Stratix ep1s10 on a development board. The
> data sheet says the IO can operate at rates up to 800 MSPS. If I have a
> look on the internet, I see DAC and ADC technology going up to 400
> MSPS.
>
> My application is software defined radio, where the general mantra is
> to do as little analog front-end as possible, i.e. sample as fast as
> you can.
>
> What are the limits on my conversion rates? I doubt it's even remotely
> possible for me to do data conversion at 400 MSPS? My main concern is
> the PCB layout, with about 15cm of track and a header between the FPGA
> and the conversion chips. Crosstalk, EMI and impedance matching are all
> things I know very little about.
>
> Is there a more appropraiate group to post on?
> 
> Thanks in advance,
> Richard


Article: 104956
Subject: Re: High-speed DAC/ADC with FPGA
From: bill.sloman@ieee.org
Date: 10 Jul 2006 15:42:18 -0700
Links: << >>  << T >>  << A >>

PeterSmith1954@googlemail.com wrote:
> rnbrady wrote:
> > Hi folks
> >
> > I'm working with an Altera Stratix ep1s10 on a development board. The
> > data sheet says the IO can operate at rates up to 800 MSPS. If I have a
> > look on the internet, I see DAC and ADC technology going up to 400
> > MSPS.
> >
> > My application is software defined radio, where the general mantra is
> > to do as little analog front-end as possible, i.e. sample as fast as
> > you can.
> >
> > What are the limits on my conversion rates? I doubt it's even remotely
> > possible for me to do data conversion at 400 MSPS? My main concern is
> > the PCB layout, with about 15cm of track and a header between the FPGA
> > and the conversion chips. Crosstalk, EMI and impedance matching are all
> > things I know very little about.
> >
> > Is there a more appropraiate group to post on?
> >
> > Thanks in advance,
> > Richard
>
> Crossposted to s.e.d.
> There's no reason you can't sample at 400MS/s with the right parts and
> proper layout. At those speeds you do have to be very careful about
> layout, and differential sampling is probably a *very* good idea.

Software radio makes life a lot more interesting than regular A/D
conversion.

The sorts of circuits that run at 400MSPS tend to be quite potent radio
transmitters, unless you are very careful about circuit layout -
classical radios had to bury the local oscillator in a shielded metal
box to stop it radiating into your antenna.

Presumably this is a soluble problem, but the OP doesn't seem to know
it exists, which could complicate life.

-- 
Bill Sloman, Nijmegen


Article: 104957
Subject: Re: DDR Controller problems
From: "David" <simianfever@gmail.com>
Date: 10 Jul 2006 18:25:43 -0700
Links: << >>  << T >>  << A >>

PeterSmith1954@googlemail.com wrote:
> David wrote:
> > Hi Peter, Nico, Saumyajit,
> >
> > Thanks for your replies. I was initially trying to use 100 MHz and I've tried slowing the OPB bus down to 66MHz - which EDK says is as slow as the Micron chip will go - but it still freezes on the memory test. The solder joints look fine to me but I'm just a Masters student - not exactly an expert!
> >
> > I checked the initialisation and found that it wasn't waiting 200 cycles after setting the mode register the second time so I fixed that but it had no effect. I checked the precharge - the period met the specifications - 7.8us. I haven't been able to check the clock relative to the commands as I only have a 100MHz scope - I can see that the signals are going up and down in roughly the right places but the time resolution is pretty lousy - I'm working on getting access to a better logic analyser.
> >
> > While I was checking the UCF for the pin configurations I noticed that in the mapper report I was getting this:
> >
> > | data<0> | IOB | BIDIR | SSTL2_I | | | OUTDDR | | | | | | | | ENFF2 |
> >
> > when according to the readme I should be getting this:
> >
> > | data<0> | IOB | BIDIR | SSTL2_I | | | INFF1 | | | | | | | INFF2 | | | | | | | OUTDDR | | | | | | | ENFF2 What do I need to set to get it to use the INFFs? (They aren't being used on the input pins either)
> >
> > Thanks again,
> >
> > David
>
> In your mapper report, you are missing the IN FF [x] reports. This
> might mean (I am no expert on these tools, although I use them... ;) ]
> that the read functtionality is not being generated and has been
> optimised out. That would certainly explain what you are seeing.
>
> Did the compiler (synthesiser)  report have any such warnings? (Note
> they may be buried in the noise on such a compile)
>
> Cheers
>
> PeteS

Hi Pete,

I can't see any warnings to that effect - here are the warnings that I
can't account for, sorry there's so many:

WARNING:Xst:37 - Unknown property "buffer_sig".
WARNING:Xst:37 - Unknown property "buffer_sig".
WARNING:Xst:37 - Unknown property "buffer_sig".
WARNING:Xst:37 - Unknown property "buffer_sig".

This is generated by this bit of code:

   attribute buffer_sig : string;
   attribute buffer_sig of clk    : signal is "IBUFG";
   attribute buffer_sig of clk_fb : signal is "IBUFG";

WARNING:Xst:37 - Unknown property "preserve_signal".
WARNING:Xst:37 - Unknown property "preserve_signal".
WARNING:Xst:37 - Unknown property "preserve_signal".
WARNING:Xst:37 - Unknown property "preserve_signal".

      attribute preserve_signal : boolean;
      attribute preserve_signal of dqsz_q : signal is true;
      attribute preserve_signal of tristate_q : signal is true;
      attribute preserve_signal of z_q : signal is true;
      attribute preserve_signal of rst_qn : signal is true;

WARNING:Xst:1748 - "C:/Memec/memtest/ddr_sdr.vhd" line 494: VHDL
Assertion Statement with non constant condition is ignored.
WARNING:Xst:37 - Unknown property "preserve_signal".
WARNING:Xst:37 - Unknown property "clock_feedback".
WARNING:Xst:37 - Unknown property "clock_feedback".
WARNING:Xst:1748 - "C:/Memec/memtest/user_if.vhd" line 244: VHDL
Assertion Statement with non constant condition is ignored.

WARNING:Xst:2404 -  FFs/Latches <w_srg_q<5:5>> (without init value)
have a constant value of 0 in block <ddr_sdr>.

WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<address_10> (without init value) has a constant value of 0 in block
<mem_fsm>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<address_11> (without init value) has a constant value of 0 in block
<mem_fsm>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<address_12> (without init value) has a constant value of 0 in block
<mem_fsm>.

WARNING:Xst:1710 - FF/Latch  <w_srg_q_1> (without init value) has a
constant value of 0 in block <ddr_sdr>.
WARNING:Xst:1710 - FF/Latch  <w_srg_q_0> (without init value) has a
constant value of 0 in block <ddr_sdr>.
WARNING:Xst:1291 - FF/Latch <shift_q_1_0> is unconnected in block
<ddr_sdr>.  x16

WARNING:Xst:1988 - Unit <user_if>: instances <Mcompar__n0026>,
<Mcompar__n0027> of unit <LPM_COMPARE_2> and unit <LPM_COMPARE_3> are
dual, second instance is removed
WARNING:Xst:1710 - FF/Latch  <address_0> (without init value) has a
constant value of 0 in block <mem_fsm>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch  <addr_0>
(without init value) has a constant value of 0 in block <mem_fsm>.

WARNING:Xst:1291 - FF/Latch <memory/dcm_error_q> is unconnected in
block <top>.
WARNING:Xst:1710 - FF/Latch  <memory/user_if_inst/addr_int_q_0>
(without init value) has a constant value of 0 in block <top>.
WARNING:Xst:1710 - FF/Latch  <memory/user_if_inst/addr_int_q_9>
(without init value) has a constant value of 0 in block <top>.
WARNING:Xst:1710 - FF/Latch  <memory/user_if_inst/addr_int_q_10>
(without init value) has a constant value of 0 in block <top>.
WARNING:Xst:1710 - FF/Latch  <memory/user_if_inst/addr_int_q_11>
(without init value) has a constant value of 0 in block <top>.
WARNING:Xst:1710 - FF/Latch  <memory/user_if_inst/addr_int_q_12>
(without init value) has a constant value of 0 in block <top>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memory/col_adr_q_0> (without init value) has a constant value of 0 in
block <top>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memory/col_adr_q_9> (without init value) has a constant value of 0 in
block <top>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memory/col_adr_q_10> (without init value) has a constant value of 0 in
block <top>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memory/col_adr_q_11> (without init value) has a constant value of 0 in
block <top>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memory/col_adr_q_12> (without init value) has a constant value of 0 in
block <top>.
WARNING:Xst:1291 - FF/Latch <memory/Mshreg_data_out_q_16> is
unconnected in block <top>.
WARNING:Xst:1291 - FF/Latch <memory/data_out_q_16> is unconnected in
block <top>.

Cheers,

David


Article: 104958
Subject: Re: LUT4 INIT value to implement 2:1 MUX ?
From: "PeterC" <peter@geckoaudio.com>
Date: 10 Jul 2006 19:48:39 -0700
Links: << >>  << T >>  << A >>

Thanks Antti, makes perfect sense.

I have written my code as follows, but FPGA Editor is telling me that
the LUT4 function is:

<G> = ((~A1*(A4*A3)) + (A1*(A4 + ~A3)))

This is clearly not a 2-input MUX!

Can anyone see any issues with the code below?

---------------------------------------------------------------
architecture
...
   attribute INIT : string;
   attribute INIT of i_lut4 : label is "CACA";

...
begin
   i_lut4 : LUT4 generic map( INIT => x"CACA")
          port map(I0 => input1, I1 => input2, I2 => select, I3 => '0',
O => output);
.... 
---------------------------------------------------------------


Article: 104959
Subject: Re: LUT4 INIT value to implement 2:1 MUX ?
From: "PeterC" <peter@geckoaudio.com>
Date: 10 Jul 2006 20:48:00 -0700
Links: << >>  << T >>  << A >>

Oh dear, please don't crucify me for this, but obviously the function
((~A1*(A4*A3)) + (A1*(A4 + ~A3))) IS indeed a 2-input MUX, with select
= A3.

I just wrote a MUX behavioural mode using a case statement, and FPGA
Editor gave the same result as instantiating a LUT4 with INIT="CACA".

It is interesting (and probably obvious to someone else) that FPGA
Editor would write the function in such a convoluted (non-minimal POS
or SOP) form.


Article: 104960
Subject: Re: PROM files: build .bin for daisy chain on the fly
From: jackhab@gmail.com
Date: 10 Jul 2006 23:29:09 -0700
Links: << >>  << T >>  << A >>
Well, I understand I'll have to parse the file structure to be able to
rebuild it. This is what I've been doing for a couple of last days.
The problem is that Xilinx app. notes describes all the PACKETS used in
file while I still have a problem undestanding the file STRUCTURE, i.e.
why are those packets are being organized in the way they are.


Article: 104961
Subject: Re: debouncing a switch (in hardware)
From: aName <anEmail@anAddress.com>
Date: Tue, 11 Jul 2006 03:44:31 -0400
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> Hi - 
> 
> On 6 Jul 2006 11:53:39 -0700, "Brian McFarland"
> <brian.mcf1985@gmail.com> wrote:
> 
> 
>>I've been messing around with my own sort of development board for an
>>Altera MAX 3064 because I have some downtime at work (I'm a coop) and
>>wanted to teach myself some PLD stuff.  I wanted ot put a manual clock
>>button on it so I could just mess around with some simple designs to
>>get a feel for how to use HDL's and Quartus.  I have some DIPs for
>>inputs and LEDs for outputs, everything run on 3.3V.   But the I can't
>>manage to get the clock to pulse just once when I press the button.
>>Can anyone recomend a debouncing circuit to use for something l like
>>this?
> 
> 
> Jack Ganssle has written extensively about this.  Here's a paper that
> summarizes his findings and design suggestions:
> 
> http://www.ganssle.com/debouncing.pdf
> 
> Bob Perlman
> Cambrian Design Works
> http://www.cambriandesign.com


I just finished implementing a small protoboard with 12 unbonced 
switches, I used a safe SRLatch type approach :-)

And it works like heaven ;-)




Article: 104962
Subject: Implementing USB slow protocol into xilink XC95xxx..
From: aName <anEmail@anAddress.com>
Date: Tue, 11 Jul 2006 03:48:19 -0400
Links: << >>  << T >>  << A >>

Implementing USB slow protocol into xilink  XC95xxx..
I don't need long vendor string and stuff like that just the basic protocol.

Is it possible ? it seems pretty complex to do ...

Article: 104963
Subject: Re: High-speed DAC/ADC with FPGA
From: "rnbrady" <rnbrady@gmail.com>
Date: 11 Jul 2006 01:26:17 -0700
Links: << >>  << T >>  << A >>
Hi guys

Thanks for the helpful replies.


> More details are really needed:
>
> What type of header are you talking about? I have run signals at 5Gb/s
> through connectors designed for the task with little loss and very low
> crosstalk, but they aren't cheap. Is this an existing header?

The headers are existing. They are standard beak-away headers.

> Does this mean you want to run wires, or are you making a circuit board
> for the A-D? You are unlikely to get high data rates with handwired
> circuitry (you can get reasonably high speeds, but not too high unless
> you are an expert in wirewrap and routing ;).

I plan to have a PCB made. We have facilities for two layer PCB
manufacturing.

> You say you are using a development board. What documentation is there
> for it? Point us at some details if you have them.

I'm working with an Altera dev kit:
http://www.altera.com/products/devkits/altera/kit-nios_1S10.html

There is tons of documentaion for the NiosII embedded CPU on this dev
kit but almost no documnetation on the board itself.

> What is the interface from your A-D converter(s)? Serial? Parallel?

I'd find it simpler to do parallel, there's no shortage of pins.

> Parallel may take more lines, but it also gives the lowest data rate.
> There are also tricks of synchronised sampling (using multiple
> converters, suitably calibrated) to increase the effective sample rate,
> should that be necessary. On that subject, is there a particular A-D
> device you have in mind, or are you open to suggestions?

Completely open.

> What signal frequency range are you particularly interested in getting?
> If you are not sure of what to use, this will let others help you
> choose an appropriate device.

I'd like to capture and generate signals anywhere from 10kHz to 100MHz.
It would be great if I could reach 450MHz with some mixing at the front
end. I don't really need more than 1MHz at a time. So a lower rate with
a NCO + mixer might be a better bet. The basic idea to to be able to
receice and transmit commercial FM and AM, plus some walkie-talkie FM,
and maybe some HAM radio, all with as little HW as possible.

>
> Even if you sample with a decent A-D, you should still (in my opinion)
> put an anti-aliasing filter on the front end, and buffering to prevent
> loading. (Some parts have them internally). Unless you have a buffered
> output from something, you are probably going to have to put down at
> least some analog circuitry apart from the A-D(s).

This is fine, I simply want to keep it to a minimum.

> Speaking of that, what RF device did you intend to use to get the
> signal in the first place?

An antenna.

>
> Answer those (reply to both groups) and some of the denizens of s.e.d.
> will no doubt dispense some ideas, and no doubt ask more questions.

Thanks again. I really appreciate your input.

Richard


Article: 104964
Subject: Re: Implementing USB slow protocol into xilink XC95xxx..
From: "Antti" <Antti.Lukats@xilant.com>
Date: 11 Jul 2006 01:31:48 -0700
Links: << >>  << T >>  << A >>
aName schrieb:

> Implementing USB slow protocol into xilink  XC95xxx..
> I don't need long vendor string and stuff like that just the basic protocol.
>
> Is it possible ? it seems pretty complex to do ...

do not try. I want say it is impossible - as only a few things are.

SiLabs F326 usb micro has internal oscillator and costs 2.36 USD qty 1.

any attempts to implemented USB with PLD or FPGA would cost more both
component cost and time spent.

Antti
http://antti-brain.com


Article: 104965
Subject: Re: PROM files: build .bin for daisy chain on the fly
From: "Antti" <Antti.Lukats@xilant.com>
Date: 11 Jul 2006 01:33:43 -0700
Links: << >>  << T >>  << A >>
jackhab@gmail.com schrieb:

> Well, I understand I'll have to parse the file structure to be able to
> rebuild it. This is what I've been doing for a couple of last days.
> The problem is that Xilinx app. notes describes all the PACKETS used in
> file while I still have a problem undestanding the file STRUCTURE, i.e.
> why are those packets are being organized in the way they are.

I have a xilinx bitstream 'dump' utility that can be used to look what
impact has done.

the bitstream composition isnt complicated

Antti


Article: 104966
Subject: Re: High-speed DAC/ADC with FPGA
From: David Brown <david@westcontrol.removethisbit.com>
Date: 11 Jul 2006 10:35:19 +0200
Links: << >>  << T >>  << A >>
rnbrady wrote:
> Hi guys
> 
> Thanks for the helpful replies.
> 
> 
>> More details are really needed:
>>
>> What type of header are you talking about? I have run signals at 5Gb/s
>> through connectors designed for the task with little loss and very low
>> crosstalk, but they aren't cheap. Is this an existing header?
> 
> The headers are existing. They are standard beak-away headers.
> 
>> Does this mean you want to run wires, or are you making a circuit board
>> for the A-D? You are unlikely to get high data rates with handwired
>> circuitry (you can get reasonably high speeds, but not too high unless
>> you are an expert in wirewrap and routing ;).
> 
> I plan to have a PCB made. We have facilities for two layer PCB
> manufacturing.
> 

I would expect you to need more than two layers for a high speed ADC card.

>> You say you are using a development board. What documentation is there
>> for it? Point us at some details if you have them.
> 
> I'm working with an Altera dev kit:
> http://www.altera.com/products/devkits/altera/kit-nios_1S10.html
> 
> There is tons of documentaion for the NiosII embedded CPU on this dev
> kit but almost no documnetation on the board itself.

The schematics for the card are available.  If it is like the Cyclone 
Nios II card, then there are buffers on the pins connected to the 
headers, which will severely limit the speed of these pins.

> 
>> What is the interface from your A-D converter(s)? Serial? Parallel?
> 
> I'd find it simpler to do parallel, there's no shortage of pins.
> 
>> Parallel may take more lines, but it also gives the lowest data rate.
>> There are also tricks of synchronised sampling (using multiple
>> converters, suitably calibrated) to increase the effective sample rate,
>> should that be necessary. On that subject, is there a particular A-D
>> device you have in mind, or are you open to suggestions?
> 
> Completely open.
> 
>> What signal frequency range are you particularly interested in getting?
>> If you are not sure of what to use, this will let others help you
>> choose an appropriate device.
> 
> I'd like to capture and generate signals anywhere from 10kHz to 100MHz.
> It would be great if I could reach 450MHz with some mixing at the front
> end. I don't really need more than 1MHz at a time. So a lower rate with
> a NCO + mixer might be a better bet. The basic idea to to be able to
> receice and transmit commercial FM and AM, plus some walkie-talkie FM,
> and maybe some HAM radio, all with as little HW as possible.
> 
>> Even if you sample with a decent A-D, you should still (in my opinion)
>> put an anti-aliasing filter on the front end, and buffering to prevent
>> loading. (Some parts have them internally). Unless you have a buffered
>> output from something, you are probably going to have to put down at
>> least some analog circuitry apart from the A-D(s).
> 
> This is fine, I simply want to keep it to a minimum.
> 
>> Speaking of that, what RF device did you intend to use to get the
>> signal in the first place?
> 
> An antenna.
> 
>> Answer those (reply to both groups) and some of the denizens of s.e.d.
>> will no doubt dispense some ideas, and no doubt ask more questions.
> 
> Thanks again. I really appreciate your input.
> 
> Richard
> 

Article: 104967
Subject: Re: High-speed DAC/ADC with FPGA
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Tue, 11 Jul 2006 10:00:22 GMT
Links: << >>  << T >>  << A >>
On a sunny day (10 Jul 2006 15:42:18 -0700) it happened bill.sloman@ieee.org
wrote in <1152571338.767516.262410@75g2000cwc.googlegroups.com>:
classical radios had to bury the local oscillator in a shielded metal
>box to stop it radiating into your antenna.

Dunno what you call 'classical', but even my tube communications receiver
in the sixties had no 'separate box' for the LO.

A RF pre-amp, folowed by a mixer would give plenty isolation.
The good old 'ECH81 ?? osc mixer tubes had it all in obne tube and no
RF pre.
Those were commercial radios.
No normal transistor radio has a boxed LO.

Modern TV tuners using dual gate MOSFETS have it all on one PCB....
Very old UHF / VHF tuners had a separate section for the LO.
But the reason was likely one of tuning, after all there was 38 MHz or
so offset.

It is true that with many transistor radios you can jam a AM MW station by
tuning 455 kHz (or whatever) next to it, but it only works on a few
meters distance.
 


Article: 104968
Subject: Programming the Spartan-3E Starter Kit using Linux?
From: buchty@atbode100.lrr.in.tum.de (Rainer Buchty)
Date: Tue, 11 Jul 2006 10:21:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello everyone,

I recently got one of the HW-SPAR3E-SK eval boards and am trying to
get ISE/IMPACT under Linux to talk to it; I have ISE8.2 installed, 
the actual Windriver compiled nicely and is also loaded:

windrvr6              110208   0
usbcore                68044   1 [windrvr6 usbserial usb-uhci ehci-hcd]

Also /dev/windrvr6 exists:

crw-rw-rw-    1 root     root     254,   0 2006-07-11 11:15 /dev/windrvr6

However, IMPACT just doesn't see the board. Checking the syslog, I find the
following when plugging in the board's USB cable into the PC:

Jul 11 12:18:02 kernel: usb.c: USB disconnect on device 00:1d.7-5 address 3
Jul 11 12:18:04 kernel: hub.c: new USB device 00:1d.7-5, assigned address 4
Jul 11 12:18:04 kernel: usb.c: USB device 4 (vend/prod 0x3fd/0xd) is not claimed by any active driver.

What am I doing wrong?

Kind regards,
        Rainer

Article: 104969
Subject: Re: High-speed DAC/ADC with FPGA
From: bill.sloman@ieee.org
Date: 11 Jul 2006 03:33:50 -0700
Links: << >>  << T >>  << A >>

Jan Panteltje wrote:
> On a sunny day (10 Jul 2006 15:42:18 -0700) it happened bill.sloman@ieee.org
> wrote in <1152571338.767516.262410@75g2000cwc.googlegroups.com>:

> > classical radios had to bury the local oscillator in a shielded metal
> >box to stop it radiating into your antenna.
>
> Dunno what you call 'classical', but even my tube communications receiver
> in the sixties had no 'separate box' for the LO.
>
> A RF pre-amp, folowed by a mixer would give plenty isolation.
> The good old 'ECH81 ?? osc mixer tubes had it all in one tube and no
> RF pre.

I'll bet that there was some internal shielding within the ECH81
oscillator/mixer tube.

> Those were commercial radios.
> No normal transistor radio has a boxed LO.

I'll take your word for it - I haven't opened up a transistor radio for
some years now.
Careful printed circuit layout, and tricks like generating
complementary/balanced signal pairs and routing them close together can
obviously minimise the radiation from the local oscillator to the point
where the shielded metal box is no longer necessary.

The point is that you have to know you need to be this careful,and you
ought to read up on the tricks of the trade. Reinventing the wheel
takes time and gives loads of opportunities to invent a whole clas of
constant cross-section rollers that don't work as well.

The OP would find it easier to get a good layout on a four or six layer
board with a buried ground plane or two, but a double-sided board
should be practical, with careful layout.

> Modern TV tuners using dual gate MOSFETS have it all on one PCB....
> Very old UHF / VHF tuners had a separate section for the LO.
> But the reason was likely one of tuning, after all there was 38 MHz or
> so offset.
>
> It is true that with many transistor radios you can jam a AM MW station by
> tuning 455 kHz (or whatever) next to it, but it only works on a few
> meters distance.

It is rather difficult to keep the electronics of a radion more than a
few metres away from  its antenna.

-- 
Bill Sloman, Nijmegen


Article: 104970
Subject: sopc -apex20ke1500xxxx
From: "nmn" <nmnaik@gmail.com>
Date: 11 Jul 2006 03:40:35 -0700
Links: << >>  << T >>  << A >>
hi all


i hav a sopc board(with apex20ke1500xxx fpga),altera quartus ii tool, i
got a sof file,

now the board is having uart,sdram and etc., stuffs

now i hav been assigned a work of testing my uart design(verilog) on
this board,

i am in confusion of procedures

if possible how?

bye


Article: 104971
Subject: Re: High-speed DAC/ADC with FPGA
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Tue, 11 Jul 2006 11:09:19 GMT
Links: << >>  << T >>  << A >>
On a sunny day (11 Jul 2006 03:33:50 -0700) it happened bill.sloman@ieee.org
wrote in <1152614030.638069.323220@b28g2000cwb.googlegroups.com>:
>> It is true that with many transistor radios you can jam a AM MW station by
>> tuning 455 kHz (or whatever) next to it, but it only works on a few
>> meters distance.
>
>It is rather difficult to keep the electronics of a radion more than a
>few metres away from  its antenna.

Well, point is, it will not jam 'itself' (for all I know).
You can jam an OTHER radio, try it, it is easy, works on FM too.
Way of topic anyways, I have looked in Tek scopes with fast AD,
not very special layout I could see, just keep it logical...
1G samples/second is normal these days.
As soon as it is 'digital' many problems become simpler.

But anyways, maybe I am a bit old-fashinoned (say older), IMO
some RF pre (selectivity and gain) before any digitising in radio makes
some sense, especially for weak signals.
I do notice a trend to connect the antenna directly to the AD chip ;-)

LC is nice.


Article: 104972
Subject: Re: PCI IOs, tiofoi, source sampling bypass
From: jean-baptiste.nouvel@jdsu.com
Date: 11 Jul 2006 04:56:11 -0700
Links: << >>  << T >>  << A >>
Hello John,

> The constraint is the same for Virtex-4 as it is for Spartan-3.  I think I'd
> use a TIG, speciying the output FFS to the input FFS.  The core's pcim_lc
> wrapper file would have the literal names for those registers and the
> Constraints Guide available in the xilinx.com online documentation would
> provide the syntax for the TIG.

I am not using the Xilinx PCI core IP but a custom target only design.
It is going to be pretty complicatted to point at all the possible
sources
(output Fifos) and all possible destinations (input Fifos) in the
design
and assign them the TIG constraint. But I guess this is the only
solution I
have.
FYI I was told that on a V4 you have the choice to assign or not to
each IO
a BYPASS attribute.

> > What would you use the DCM for?
>
> If you can gurantee a clock is always present and stable, the DCM can
> improve the I/O timing for the FPGA.  I believe the Tcko to Tsu requirement
> is actually less when the DCM is used but I haven't compared the non-DCM
> numbers lately.  I've found it helpful to tune the Tcko (or Tckon) times
> relative to the PCI clock pad to be at the PCI timing limits and manipulate
> the placement for best Tsu.

Yes. I had not thought of that.

> I don't believe the -4 speed grade can give you PCI compliance so PCI
> compatible operation is probably your goal.  You can look at your system
> timing budget using the PCI numbers as a guide but make the engineering
> decisions on your own implementation.  Just improving on clock skew from the
> 2 ns datum for 33 MHz PCI is a lot of time to recoup as long as you can
> guarantee the skew for all elements in the system (such as a plug-in board
> from another manufacturer).

You are right I just need to be PCI compatible.
The skew is controlled on my embedded system and will be much less than
1ns.
I reckon Tprop will be less than 10ns as well (short traces, 33MHz
operation).

Thank you,
jb


Article: 104973
Subject: Re: PCI IOs, tiofoi, source sampling bypass
From: jean-baptiste.nouvel@jdsu.com
Date: 11 Jul 2006 04:57:59 -0700
Links: << >>  << T >>  << A >>
Thank you Eric.
I found what you are referring to in the PCI Spec. rev.2.3, Chapter
3.10-9

"Special Design Considerations"

"Devices cannot drive and receive signals at the same time
------------------------------------------------------------------------------------
Bus timing requires that no device both drive and receive
a signal on the bus at the same time. System timing
analysis considers the worst signal propagation case to be
when one device drives a signal and the signal settles at the
 input of all other devices on the bus. In most cases, the signal
will not settle at the driving device until some time after it
 has settled at all other devices. Refer to Section 4.3.5. and
Section 7.7.5. for a description of Tprop.
Logic internal to a device must never use the signal received
from the bus while that device is driving the bus. If internal
 logic requires the state of a bus signal while the
device is driving the bus, that logic must use the internal
signal (the one going to the output buffer of the device) rather
than the signal received from the device input
buffer. For example, if logic internal to a device continuously
monitors the state of FRAME# on the bus, that logic must use
the signal from the device input buffer when the device is not the
current bus master, and it must use the internally generated
FRAME# when the device is the current bus master."

It makes sense now.

Thank you for your help.

jb


Article: 104974
Subject: Development Boards -Your chance to suggest features
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Tue, 11 Jul 2006 13:19:57 +0100
Links: << >>  << T >>  << A >>
Following our recent Swinyard1 (Virtex-4) release we are now looking at the 
Swinyard2 module concept which will be based on a middle end Virtex-5 
(initial XC5VLX50 and others) that will be supported by our Broaddown series 
of main development boards. Bearing in mind this a small module what 
features would you like us to put on this module?

and what did you all think of the general Swinyard concept?

This is you chance to influence what we deliver to the marketplace so do let 
us know.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk





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
2017JanFebMarApr2017

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