Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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? > > TommyArticle: 104951
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
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
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, RichardArticle: 104954
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 PeteSArticle: 104955
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, > RichardArticle: 104956
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, NijmegenArticle: 104957
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
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: 104959Oh 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
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
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
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
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. RichardArticle: 104964
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.comArticle: 104965
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 AnttiArticle: 104966
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
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
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: 104969Jan 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, NijmegenArticle: 104970
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? byeArticle: 104971
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
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, jbArticle: 104973
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. jbArticle: 104974
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:
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